Genkit : un SDK multi-langages pour les applications agentiques

Le problème concret : changer de modèle sans réécrire son application

Chaque fournisseur de modèle expose sa propre API, ses propres formats de messages, ses propres conventions pour les appels d'outils. Une équipe qui commence avec un modèle et veut en essayer un autre se retrouve à réécrire la couche d'intégration. Genkit répond à ce problème en proposant une interface unifiée vers des fournisseurs comme Google, OpenAI, Anthropic ou Ollama. Le README mentionne explicitement des plugins pour chacun. L'utilisateur cible est une équipe qui construit des chatbots, des systèmes de recommandation ou des automatisations, et qui veut déployer côté serveur. Le README précise que le framework est conçu pour un déploiement serveur, avec des helpers côté client via des SDK dédiés. Ce n'est pas une bibliothèque pour prototyper dans un notebook. C'est une couche d'orchestration pour du code qui part en production.

Ce que fait réellement le SDK entre votre code et le modèle

L'initialisation tient en quelques lignes. Le README donne cet exemple en TypeScript : on importe genkit et le plugin googleAI, on appelle genkit avec la liste des plugins, puis ai.generate avec un modèle et un prompt. La valeur de retour expose un champ text. À partir de là, le SDK prend en charge la génération de texte et d'images, la sortie structurée typée, l'appel d'outils, le templating de prompts, les interfaces de chat persistées, les workflows IA et la récupération de données pour le RAG. Ces éléments sont listés dans le README et renvoient à la documentation. Le mécanisme central est donc une couche d'abstraction : votre code décrit un modèle, un prompt et éventuellement des outils, et le SDK traduit cela vers l'API du fournisseur choisi. Le README ne détaille pas l'implémentation interne de cette traduction. On sait seulement que les plugins sont le point d'extension. Pour les workflows, le README renvoie à une page dédiée sans décrire le format. C'est une lacune de la documentation d'entrée : un lecteur qui veut comprendre comment un flow est sérialisé ou exécuté devra consulter la documentation complète.

Quatre langages, quatre niveaux de maturité

C'est le point le plus important et le plus facile à manquer. Le README classe les SDK explicitement. JavaScript/TypeScript est prêt pour la production avec support complet. Go est prêt pour la production avec support complet. Python est en Beta, avec un support large mais pas encore au niveau production. Dart est en Preview, en développement précoce avec les fonctionnalités de base. Les releases récentes confirment ce rythme : py/v0.11.0 pour Python, go/v1.13.1 et go/v1.13.0 pour Go, tous datés de septembre 2026. Le README annonce des APIs cohérentes entre langages, mais la cohérence des APIs ne signifie pas la parité des fonctionnalités. Une équipe qui choisit Python ou Dart pour la disponibilité de ses développeurs prend un risque de retard sur les fonctionnalités avancées. Ce n'est pas une critique du projet : c'est une contrainte de portée. Un framework multi-langages avance au rythme de ses équipes par langage. Le README ne donne aucune date de passage en production pour Python ou Dart.

Installation et première exécution

Le README décrit un chemin en quatre étapes : choisir le langage et le fournisseur, installer le SDK et initialiser, écrire et tester les fonctionnalités, déployer et surveiller. Pour l'installation, le README indique qu'il faut installer le SDK Genkit, le paquet du fournisseur de modèles et la CLI Genkit. Il ne donne pas les commandes exactes dans le texte fourni : elles se trouvent dans la documentation liée. L'exemple de code montre l'initialisation avec googleAI() et l'appel ai.generate avec googleAI.model('gemini-flash-latest'). Le README précise que certains fournisseurs comme Vertex AI peuvent utiliser un autre mode d'authentification qu'une clé API. C'est un détail pratique : si vous passez par Vertex AI, prévoyez la configuration d'identité correspondante plutôt qu'une variable d'environnement contenant une clé. La CLI et l'interface Developer UI servent à tester les prompts et les flows sur des entrées individuelles ou des jeux de données, comparer les sorties de différents modèles et examiner les traces d'exécution. Ces outils sont locaux selon le README.

Déploiement et observabilité : ce qui est documenté et ce qui ne l'est pas

Le README cite trois cibles de déploiement : Cloud Functions for Firebase, Google Cloud Run, et des plateformes tierces via la page deploy-node. Il insiste sur le fait que le déploiement peut se faire avec ou sans services Google. C'est une affirmation de portabilité que la documentation doit confirmer plateforme par plateforme. Pour la surveillance en production, le README mentionne un tableau de bord dédié, avec suivi des performances des modèles, des volumes de requêtes, de la latence et des taux d'erreur. Il précise aussi que la surveillance se fait dans la console Firebase. Cette dernière mention est importante : l'observabilité décrite semble passer par Firebase. Le README ne décrit pas de mécanisme d'export vers un autre backend d'observabilité. Une équipe qui n'utilise pas Firebase devra vérifier ce point avant de s'engager. Le README ne donne aucun chiffre de performance, aucun nombre d'utilisateurs, et je n'en inventerai pas. La seule affirmation de production vient du README : le framework est construit et utilisé en production par Firebase chez Google.

Les cas où Genkit n'est pas le bon outil

Premier cas : une équipe qui a besoin de fonctionnalités avancées en Python ou en Dart. Le README classe Python en Beta et Dart en Preview. Écrire une application critique sur un SDK Preview, c'est accepter des ruptures d'API. Deuxième cas : une équipe qui n'utilise qu'un seul fournisseur de modèles et n'a pas l'intention d'en changer. La couche d'abstraction ajoute une dépendance et une surface d'apprentissage sans bénéfice immédiat. Troisième cas : une équipe qui veut un contrôle total sur les paramètres propres à un fournisseur. Une interface unifiée expose par définition l'intersection des capacités, ou des échappatoires spécifiques que le README ne détaille pas. Quatrième cas : un projet qui refuse toute dépendance à Firebase pour l'observabilité et le déploiement. Le README mentionne des alternatives, mais la console Firebase revient dans la description de la surveillance. Enfin, un point de licence : le projet est sous Apache-2.0. Cette licence autorise l'usage commercial et la modification, avec des obligations de conservation des mentions et de l'état des modifications. Ce n'est pas un avis juridique, et une équipe qui redistribue le framework doit lire le texte de la licence.

Face à quoi : les SDK natifs des fournisseurs

L'alternative la plus directe est le SDK officiel du fournisseur de modèles. Si vous utilisez Google Gemini, le SDK Google AI ou Vertex AI expose les paramètres propres au modèle, les fonctionnalités les plus récentes, et une documentation alignée sur le rythme du fournisseur. La différence d'approche est nette : un SDK natif optimise la profondeur sur un fournisseur, Genkit optimise la portabilité entre fournisseurs. Concrètement, avec un SDK natif, changer de modèle signifie changer d'imports, de formats de messages et souvent de logique d'appel d'outils. Avec Genkit, le README promet une interface unifiée, mais vous dépendez de la mise à jour du plugin Genkit pour accéder aux nouveautés du fournisseur. C'est le compromis classique de toute couche d'abstraction. Il n'y a pas de réponse universelle : la question est de savoir si vous prévoyez de changer de fournisseur, ou si vous voulez la dernière fonctionnalité dès sa sortie. Le README ne documente pas de politique de mise à jour des plugins par rapport aux sorties des fournisseurs, ce qui rend ce délai difficile à évaluer à l'avance.

Maintenance et coût de mise à jour

Le dépôt n'est pas archivé et la dernière poussée date de septembre 2026. Les releases récentes montrent un rythme actif sur Go et Python. Le versionnage est par langage : py/v0.11.0, go/v1.13.1. Cette séparation signifie que vous suivez les versions de votre SDK, pas une version unique du projet. Pour une équipe TypeScript ou Go, la stabilité annoncée réduit le coût des mises à jour. Pour une équipe Python ou Dart, le coût est plus élevé : un SDK en Beta ou Preview peut introduire des changements incompatibles entre versions mineures. Le README ne donne pas de politique de dépréciation ni de calendrier de support. La licence Apache-2.0 n'impose pas de contribution en retour et permet de modifier le code, mais elle impose de conserver les notices de licence et de copyright, et de signaler les fichiers modifiés. Une équipe qui forke doit en tenir compte. Le coût réel de maintenance dépend surtout du nombre de plugins de fournisseurs que vous utilisez : chacun est un point de mise à jour potentiel.

Conclusion éditoriale

Adoptez Genkit si vous écrivez du JavaScript/TypeScript ou du Go côté serveur et voulez changer de fournisseur de modèle sans réécrire votre logique. Évitez-le si votre équipe est en Dart ou Python et dépend de fonctionnalités avancées : ces SDK sont en Preview et en Beta. Avant de vous engager, vérifiez la version de l'interface Developer UI et testez la compatibilité de votre fournisseur de modèles avec le SDK de votre langage.

Sources officielles

1. genkit-ai/genkit on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases