Manifeste
Construire des systèmes agentiques avec méthode, gouvernance et clarté.
Le manifeste ADLC (Agentic Development Lifecycle) définit des principes communs pour concevoir des systèmes agentiques gouvernés, indépendants des outils et guidés par un cycle de vie explicite.
Manifeste ADLC
L’ADLC ne remplace pas le SDLC : il conserve ses pratiques d’ingénierie et les étend pour gouverner les logiciels développés avec des agents et les systèmes agentiques en production.
L'ADLC s'applique aussi bien aux logiciels développés avec l'aide d'agents qu'aux systèmes qui emploient des agents en production.
Dans le premier cas, il gouverne les changements générés, la vérification par rapport aux exigences et la responsabilité humaine dans l'acceptation. Dans le second, il étend ces contrôles au comportement en exécution, à la connaissance, aux outils et à l'autonomie des agents.
Il ne se confond ni avec la programmation autonome ni avec la seule sécurité du code généré par l'AI : il exige des preuves vérifiables et des responsabilités explicites tout au long du cycle de vie.
La source du Manifeste ADLC, la licence, les lignes directrices de contribution et les fichiers du site sont disponibles dans le dépôt public.
Principes
Chaque initiative commence par des exigences vérifiées, compréhensibles et suffisamment mûres pour réduire l’ambiguïté et les reprises.
Les composants, agents et capacités doivent être conçus pour être réutilisés, connectés et orchestrés dans le temps.
Les outils aident, mais ne doivent pas dicter l’architecture : le processus et la gouvernance passent avant l’outil.
Tous les problèmes ne nécessitent pas un agent, et davantage d'agents ne produisent pas nécessairement de meilleurs résultats. Choisir la solution la moins complexe qui satisfait les exigences approuvées, en accordant uniquement l'autonomie nécessaire. Justifier la complexité supplémentaire par des bénéfices mesurables par rapport à une solution plus simple.
Permissions, approbations, budgets et contrôles d'arrêt sont appliqués au runtime, pas seulement décrits dans les prompts.
Contrôles de gouvernance
La supervision humaine est une couche de contrôle obligatoire dans l'ADLC, en particulier lors de l'approbation des exigences, de la validation de la qualité, de l'autorisation des releases et de la gouvernance en production.
Les agents accélèrent et structurent le travail, mais les décisions critiques et responsables restent humaines.
Une supervision compétente, pas une approbation de pure forme.
Les personnes qui approuvent doivent être formées au domaine, aux limites des agents et aux risques des décisions, avec des exercices sur les erreurs et incidents proportionnés au risque. Elles doivent disposer de preuves, sources, incertitudes et conséquences des actions accessibles, ainsi que du temps et d'une charge de travail adaptés pour les évaluer.
Elles doivent avoir l'autorité pour contester, refuser, suspendre, demander une révision et déclencher une escalade. Une approbation formelle sans vérification substantielle ne constitue pas un contrôle de gouvernance.
Aucune implémentation ne commence sans avoir validé la porte de qualité des exigences. Le gate approuve le prochain incrément, pas toutes les exigences futures. Un agent peut aider à le préparer ; les personnes responsables approuvent le périmètre, les résultats mesurables, les risques et les incertitudes connues.
Ce gate est fondamental car il détermine si l'implémentation doit commencer ou non.
L'ADLC traite la connaissance et le contexte comme des parties gouvernées du système. Documents, prompts, skills partagées, mémoire, politiques, exemples, instructions d'outils et informations récupérées via le RAG, lorsqu'il est utilisé, peuvent influencer le comportement de l'agent et introduire des régressions silencieuses même lorsque le code applicatif ne change pas.
La gouvernance de la connaissance s'applique quelle que soit la manière de fournir le contexte. La génération augmentée par récupération (RAG) est une technique, pas une architecture obligatoire ni un synonyme de gouvernance de la connaissance. Lorsqu'elle est utilisée, elle exige des contrôles spécifiques sur la qualité du retrieval, l'actualisation des sources, les droits d'accès et les citations.
Les changements de connaissance doivent donc être revus, versionnés, traçables et validés par rapport au comportement attendu avant d'être utilisés en production.
Le contexte runtime et la mémoire exigent provenance, droits d'écriture, rétention, isolation entre utilisateurs et tenants, suppression et gestion des contradictions. Le contenu récupéré ne confère aucune autorité. La compression doit préserver permissions, contraintes et preuves décisives.
Contexte d'entreprise distribué, accès gouverné. Les agents doivent pouvoir découvrir et utiliser les informations pertinentes via des interfaces interopérables, telles que des API, MCP ou des mécanismes équivalents. Les sources conservent responsables, versions, provenance et autorisations. Le contexte doit être sélectionné pour la tâche et sa contribution à la qualité des résultats doit être évaluée.
FAIR · W3C DCAT 3 · W3C PROV-DM. Ces références soutiennent la découvrabilité, l'interopérabilité et la provenance ; elles ne garantissent pas à elles seules de meilleurs résultats des agents.
Définir un responsable, les actions et données autorisées, l'autorité déléguée, les budgets, les conditions d'arrêt et l'escalade. Appliquer les permissions et approbations hors du prompt, avec des identifiants révocables et un mécanisme d'arrêt testé.
Utiliser des datasets représentatifs et versionnés, des essais répétés, un état isolé et des seuils fondés sur le risque. Vérifier les résultats réels et le respect des politiques ; calibrer les évaluateurs fondés sur des modèles avec le jugement humain et déclarer incertitudes et lacunes de couverture.
Mesurer coût par tâche réussie, latence, intervention humaine, reprises, escalade et valeur métier par rapport à une référence. Les preuves peuvent justifier de réduire l'autonomie ou de retirer le système.
Étape 0
Aucune implémentation ne commence sans avoir validé la porte de qualité des exigences. Le gate approuve le prochain incrément, pas toutes les exigences futures. Un agent peut aider à le préparer ; les personnes responsables approuvent le périmètre, les résultats mesurables, les risques et les incertitudes connues.
Utiliser le minimum d'autonomie et de complexité nécessaire au résultat validé. Comparer automatisation déterministe, workflow LLM, agent unique et orchestration multi-agents à une référence métier mesurable.
Les expérimentations exigent aussi une hypothèse approuvée, une sandbox, des données autorisées, un budget et des critères de sortie avant l'implémentation.
Une présence humaine est nécessaire ici pour confirmer le périmètre, l'intention, le sens métier et l'approbation avant le démarrage du lifecycle.
Cycle de vie ADLC
Aucune implémentation ne commence sans avoir validé la porte de qualité des exigences. Le gate approuve le prochain incrément, pas toutes les exigences futures. Un agent peut aider à le préparer ; les personnes responsables approuvent le périmètre, les résultats mesurables, les risques et les incertitudes connues.
Human in the loop : approbation obligatoire de la qualité et de l'intention des exigences.
Transformer les exigences approuvées en capacités concrètes, services, prompts, flux, intégrations et composants réutilisables. C’est l’étape où l’intention devient une solution réelle, structurée de façon à pouvoir être revue, testée, gouvernée et améliorée dans le temps sans perdre sa cohérence architecturale.
Implémenter le contrat d'autonomie avec accès au moindre privilège, politiques appliquées au runtime, budgets et contrôles d'arrêt. Les personnes restent concepteurs et développeurs, en plus de leur rôle de reviewer.
Examiner la solution sous l’angle de la qualité, de la cohérence, de la sécurité, de la maintenabilité et de l’alignement avec les principes du manifeste avant la validation.
Human in the loop : revue experte, jugement sur le risque et décision d'avancer.
Examiner autorité déléguée, frontières de confiance, gestion de la mémoire, qualité des évaluations et plans de récupération, y compris les effets irréversibles.
Valider le comportement attendu, les cas limites, les modes de défaillance, la fiabilité et la préparation opérationnelle grâce à des preuves de test structurées et à des critères d’acceptation mesurables.
Les tests couvrent aussi les régressions comportementales causées par des changements de prompts, de contenu RAG, de shared skills, de configuration du modèle, d'outils et de règles d'orchestration.
Utiliser des datasets représentatifs et versionnés, des essais répétés, un état isolé et des seuils fondés sur le risque. Vérifier les résultats réels et le respect des politiques ; calibrer les évaluateurs fondés sur des modèles avec le jugement humain et déclarer incertitudes et lacunes de couverture.
La validation du logiciel produit par des agents exige une supervision humaine compétente. Les personnes responsables approuvent les critères d'acceptation, examinent la pertinence des tests et évaluent les preuves et le risque résiduel pour autoriser la release. Les agents peuvent générer et exécuter des tests, mais ne peuvent approuver leur propre travail ni affaiblir unilatéralement ses conditions d'acceptation. Un second agent ne remplace pas la responsabilité humaine ; la profondeur de la revue est proportionnée au risque, sans imposer l'exécution manuelle de chaque test.
Mettre en production de façon contrôlée, observable et répétable, avec rollback, release notes, ownership et preuves de déploiement clairement définis.
Les preuves de release doivent identifier les changements de code, de prompts, de RAG ou de documentation, d'outils, de configuration du modèle et d'orchestration.
Human in the loop : autorisation de release et responsabilité du go-live.
Distinguer rollback de configuration, restauration de l'état et compensation des effets externes. Les actions irréversibles exigent des contrôles préventifs et une approbation explicite : un rollback ne peut pas annuler chaque action.
Faire fonctionner la solution avec monitoring, alertes, runbooks, flux de support et checkpoints de gouvernance qui maintiennent le système fiable en conditions réelles.
Les opérations doivent surveiller non seulement la santé technique, mais aussi la dérive comportementale, les réponses inattendues, l'utilisation de connaissances obsolètes, les échecs de retrieval et les régressions introduites par les mises à jour de connaissance.
Human in the loop : gestion des incidents, escalade et supervision de gouvernance en production.
Limiter les nouvelles tentatives et éviter les effets dupliqués. Tester fonctionnement dégradé, escalade, arrêt et révocation. Mesurer coût par tâche réussie, latence, intervention humaine, reprises, escalade et valeur métier par rapport à une référence. Les preuves peuvent justifier de réduire l'autonomie ou de retirer le système.
Améliorer en continu à partir du feedback de production, des incidents, de l’analytics, des retours utilisateurs et des apprentissages de delivery qui révèlent quoi affiner ensuite.
Utiliser les preuves de production pour réduire l'autonomie ou retirer les systèmes dont la valeur ou la fiabilité est insuffisante. Révoquer identifiants, endpoints et tâches planifiées ; conserver ou supprimer la mémoire selon les politiques approuvées.
Coordonner agents, flux, politiques et capacités réutilisables dans un écosystème composable capable de dépasser des implémentations isolées.
Propager identité, limites de permissions, budgets, état des approbations et traçabilité lors des délégations. Gouverner état partagé et mémoire sans élargir implicitement l'autorité.
ADLC Operating Model
Exigences validées, intention métier explicite, ownership désignée et quality gate franchi avant toute activité de build.
Utiliser cette checklist pour valider les preuves, sans répéter les activités du cycle de vie. Nommer les responsables humains ; la profondeur de revue dépend du risque et l'exécution peut être automatisée. Tout contrôle obligatoire en échec bloque la progression. Exploitation et orchestration exigent des contrôles continus, pas un unique gate de sortie.
Baseline d'implémentation
Les principes deviennent opérationnels uniquement lorsqu'ils sont traduits en contrôles répétables, vérifications mesurables et preuves révisables.
Requirements quality gate franchi, critères d'acceptation mesurables et responsables métier, techniques et risque identifiés.
Code, prompts, connaissance, sources RAG, shared skills, configuration du modèle, descriptions des outils et règles d'orchestration sont des inputs contrôlés et versionnés.
Tests, évaluations, contrôles de policy et approbations obligatoires s'exécutent dans les pipelines et bloquent la promotion lorsqu'un contrôle requis échoue.
Des datasets d'évaluation versionnés couvrent le comportement attendu, les edge cases, les actions non sûres, la qualité du retrieval, l'escalade et les régressions.
Chaque release comprend des preuves approuvées, un inventaire complet des changements, une autorisation responsable et des plans de récupération testés pour configuration, état et effets externes.
Tracing, événements d'audit, signaux de qualité, drift, échecs de retrieval, incidents et feedback humain alimentent la boucle d'amélioration gouvernée.
Checklist de conformité ADLC
SDLC et ADLC
| Caractéristique | SDLC traditionnel | ADLC |
|---|---|---|
| Exécution principale | Delivery logicielle dirigée par les personnes | Delivery coordonnée entre personnes et agents, avec une responsabilité humaine explicite |
| Comportement | Principalement déterministe et guidé par le code | Également non déterministe, adaptatif et influencé par le contexte runtime |
| Surface de changement contrôlée | Code source, configuration, infrastructure et données | Également prompts, connaissance et RAG, skills, configuration du modèle, outils et orchestration |
| Validation | Tests de code, d'intégration, système, sécurité et acceptation | Les mêmes contrôles plus une évaluation continue du comportement, du retrieval et des régressions |
| Rôle humain | Auteur, reviewer, approbateur et opérateur | Concepteur, développeur, opérateur, reviewer, approbateur, responsable de l'escalade et des décisions |
| Preuves | Records de build, test, approbation et release | Traçabilité end-to-end de l'exigence au comportement, aux preuves, à la release et aux opérations |
ADLC en pratique
En pratique, l'ADLC ne fonctionne pas comme une pipeline à sens unique. Les équipes entrent par le quality gate des exigences, traversent la delivery puis reviennent dans la boucle via l'exploitation, l'amélioration et l'orchestration.
Skills partagees
Les shared skills peuvent partir de frameworks consolides, mais elles doivent etre adaptees a l'architecture, aux politiques, au vocabulaire, au modele de risque et a la culture de delivery de l'entreprise.
Elles transforment le know-how reutilisable en patterns d'execution gouvernes que les agents et les equipes peuvent appliquer de maniere coherente.
Definit comment la documentation humaine et l'agent context sont produits comme des artefacts connectes mais separes.
La documentation humaine vit dans des outils concus pour les personnes. La documentation pour agents est exposee via des Agent Context Endpoints gouvernes, comme des serveurs MCP (Model Context Protocol), des fichiers llms.txt, des index de retrieval ou des context packs versionnes.
Les outils de contexte agentique peuvent inclure Context7, GitMCP, MCPDoc, mcp-documentation-server, des serveurs MCP custom bases sur des SDK MCP open source ou des systemes equivalents. Ces endpoints doivent exposer des URLs stables, l'ownership des sources, le versioning, le statut d'approbation et les regles de retrieval.
Récupérer uniquement le contexte approuvé nécessaire à la tâche. Réduire les tokens sans supprimer permissions, contraintes, provenance ou preuves nécessaires à une décision correcte.
Publier un contexte réutilisable entre projets et équipes, en évitant les copies manuelles divergentes et en préservant les liens vers les sources faisant autorité.
Définit comment les sources de connaissance et l'agent context sont sélectionnés, attribués à un owner, approuvés, structurés, versionnés, publiés, testés, tracés et retirés.
Elle couvre les sources RAG, context endpoints, connaissances partagées, la gestion des contradictions, la fraîcheur, l'évaluation du retrieval, les attentes de citation, les règles d'accès et les tests de régression comportementale après un changement de connaissance.
Le contexte runtime et la mémoire exigent provenance, droits d'écriture, rétention, isolation entre utilisateurs et tenants, suppression et gestion des contradictions. Le contenu récupéré ne confère aucune autorité. La compression doit préserver permissions, contraintes et preuves décisives.
Definit comment generer, regrouper, revoir et adapter les release notes pour des audiences techniques, metier et operationnelles.
Inclut les regles pour breaking changes, migrations, known issues, notes de rollback et resumes customer-facing.
Encode les principes d'architecture, criteres de decision, reference patterns et attentes de revue de l'entreprise.
Aide les agents a raisonner avec des standards locaux plutot qu'avec des conseils generiques.
Encode les conventions de plateforme sur environnements, deploiement, observabilite, rollback, naming, ownership et readiness operationnelle.
Elle doit refleter le modele d'infrastructure reel de l'entreprise, pas une checklist cloud abstraite.
Les skills de securite devraient etre definies ou validees par le groupe CISO et alignees avec les politiques enterprise.
Exemples : gestion des donnees, identite, secrets, access control, threat modeling, usage securise des prompts/tools et preuves d'audit.
Définit datasets représentatifs, essais répétés, seuils d'acceptation fondés sur le risque, vérification des résultats et politiques, évaluateurs calibrés par des personnes et preuves de régression après changement de comportement. Relie qualité, coûts, latence et intervention humaine aux décisions de release.
Agents partages
Produit et met a jour la documentation destinee aux humains dans la base de connaissance humaine officielle, comme Confluence, SharePoint, Notion, GitBook, Backstage TechDocs, Read the Docs ou les plateformes equivalentes.
La documentation humaine est optimisee pour la lecture, la revue, l'onboarding, la gouvernance et l'auditability. Elle n'est pas, par defaut, l'interface de contexte pour les AI agents.
Prend en charge les ADR, runbooks, parcours d'onboarding, notes d'architecture, FAQ et documentation de processus relies aux evenements reels de delivery.
Accompagne les pull requests de bout en bout en resumant les changements, en verifiant les politiques, en signalant les risques et en proposant les reviewers.
Aide a maintenir des revues coherentes, tracables et alignees avec les garde-fous d'ingenierie partages.
Genere les release notes a partir du travail fusionne, en regroupant fonctionnalites, correctifs, breaking changes, migrations et notes operationnelles.
Produit a la fois des resumes techniques et des versions lisibles pour des audiences metier.
Detecte les ecarts entre code, tickets, releases et documentation, puis propose ou effectue les mises a jour manquantes.
Maintient l'alignement entre la realite de la delivery et la base de connaissance dans le temps.
Passe en revue et gouverne les sources de connaissance et d'agent context avant leur utilisation par les agents. Il vérifie fraîcheur, ownership, statut d'approbation et version, duplication, contradictions, validité métier, traçabilité, qualité du retrieval et impact de régression.
Il aide à garantir que les documents, context endpoints, contenus RAG et connaissances partagées améliorent le comportement des agents sans introduire de changement non contrôlé.
Relie exigences, implementations, tests, documentation et releases dans une chaine d'evidence auditable.
Soutient les quality gates, les revues et les checkpoints de gouvernance tout au long du lifecycle.
Verifie que chaque release dispose de runbooks, d'ownership, de guides de rollback, d'alertes et de preuves de préparation opérationnelle.
Aide les equipes a passer du deploiement a une operation stable avec moins d'angles morts.
Capacités d'outillage
Cette carte ADLC regroupe des capacités d'outillage au service de ses contrôles, en s'appuyant sur des standards et pratiques techniques établis et émergents. Ce n'est ni une taxonomie normative ni une stack obligatoire : un outil peut couvrir plusieurs capacités et les services d'entreprise existants peuvent être réutilisés. Choisir les implémentations selon le périmètre approuvé, le risque et l'architecture.
Le retrieval est nécessaire uniquement lorsque le système récupère des connaissances externes ; les workflows persistants conviennent lorsque l'exécution doit survivre aux interruptions ou coordonner des actions de longue durée. Un gateway multi-fournisseurs est optionnel lorsqu'il faut centraliser l'accès aux modèles ou le routage. Ces composants ne remplacent ni le quality gate des exigences ni la supervision humaine responsable.
Les références étayent les capacités sous-jacentes, pas cette classification précise ni la conformité ADLC. Les standards et frameworks décrivent des processus ou contrôles ; la recherche étudie des méthodes spécifiques ; la documentation technique illustre des implémentations.
| Capacité | Ce qu'il faut utiliser | Contrôle à démontrer |
|---|---|---|
| Exigences et traçabilité Standard: ISO/IEC/IEEE 29148 | Un registre d'exigences relié aux décisions, tests et releases. | Périmètre approuvé, critères d'acceptation mesurables, responsables et quality gate validé. |
| Versionnement et delivery Framework: NIST SSDF | Gestion de versions, stockage d'artefacts et pipelines de delivery automatisés. | Changements révisables du code, des prompts, skills et configurations ; promotion bloquée si les contrôles obligatoires échouent. |
| Connaissance, contexte et documentation Documentation technique: Context engineering | Documentation humaine et interface séparée de contexte pour agents, catalogue des sources, index de retrieval et politiques de mémoire selon les besoins. | Responsables, approbation, provenance, fraîcheur, accès, rétention et suppression des sources ; le contexte doit préserver les contraintes. |
| Identité et accès délégué Standard: RFC 8693 | Fournisseur d'identité, identités de service, contrôles d'autorisation et gestionnaire de secrets. | Qui agit, au nom de qui et avec quelles permissions ; moindre privilège, délégation limitée, expiration et révocation. |
| Politiques runtime et limites de consommation Documentation technique: Policy enforcement Documentation technique: Gateway budgets | Application des politiques aux interfaces des outils, compteurs d'utilisation, quotas et contrôles d'arrêt. | Limites d'actions, dépenses, durée, appels et tentatives ; les actions interdites sont bloquées, pas seulement journalisées. |
| Orchestration et récupération Documentation technique: Durable execution | Des contrôles d'exécution et procédures de récupération ; un moteur de workflows persistant lorsque la reprise ou la coordination d'actions de longue durée est nécessaire. | Reprise d'exécution, idempotence, conditions d'arrêt, réconciliation de l'état et compensation autorisée. |
| Revue humaine Framework: NIST AI 600-1 | Une file de revue avec preuves, affectation aux reviewers autorisés, expiration et escalade. | Les reviewers formés peuvent contester ou arrêter les actions ; approbation liée à l'action exacte, avec preuves de décision et sans approbation implicite à l'expiration. |
| Évaluation comportementale Documentation technique: Agent evaluations | Datasets de test versionnés, moteurs d'évaluation, tests adversariaux et calibration humaine. | Essais répétés, résultats réels, respect des politiques, seuils fondés sur le risque et gates de régression. |
| Observabilité, coûts et résultats Documentation technique: OpenTelemetry GenAI | Traces, métriques, alertes, suivi des coûts et tableaux de bord opérationnels. | Dérive comportementale, échecs de retrieval, coût par tâche réussie, latence, intervention humaine et résultats métier. La télémétrie seule ne démontre pas la valeur métier ; évaluer les résultats par rapport à une référence approuvée. |
| Audit et incidents Documentation technique: Decision logs Framework: NIST SP 800-61r3 | Stockage protégé des preuves, workflows de gestion des incidents et runbooks opérationnels. | Reconstituer décisions et changements, gérer les incidents, tester la récupération et retirer accès et données selon les politiques. |
| LLM Gateway et routage des modèles Recherche: RouteLLM Documentation technique: LLM gateway | Selon les besoins, un gateway multi-fournisseurs avec routage évalué, politiques de tokens entrants/sortants, cache et contrôle de consommation. | Choix de modèles approuvés, preuves distinctes des consommations entrée/sortie, dépenses bornées et optimisation préservant la qualité. |
Vérifier SSO (Single Sign-On) et rôles, isolation entre tenants, rétention et suppression, preuves d'audit exportables, hébergement et résidence des données, support opérationnel et intégration aux contrôles existants. La licence open source seule ne garantit pas l'adéquation.
Exemples de tooling enterprise
Ces exemples ne sont pas normatifs. L'utilisation d'un produit ne rend pas à elle seule une équipe alignée avec l'ADLC : les contrôles, les preuves, l'ownership et les décisions responsables restent obligatoires.
| Capacité | Outil | Usage enterprise | Statut open source | URL |
|---|---|---|---|---|
| Exigences et approbations | Jira | Exigences structurées, workflows, approbations, ownership et records de traçabilité. | Non - commercial | https://www.atlassian.com/software/jira |
| Delivery et gates de preuve | GitLab | Gestion de versions, revue, CI/CD, policy gates, contrôles de sécurité et preuves de release. | Open core - CE est MIT ; les fonctions enterprise sont propriétaires | https://about.gitlab.com/ |
| Tests comportementaux | promptfoo | Évaluations de prompts, RAG, agents et red teaming exécutables localement ou dans les pipelines CI. | Oui - projet MIT ; offre enterprise commerciale | https://www.promptfoo.dev/ |
| Tracing et évaluation | Langfuse | Tracing, gestion des prompts, datasets d'évaluation, expériences et feedback de production. | Open core - le cœur est MIT ; les add-ons enterprise sont commerciaux | https://langfuse.com/ |
| Décisions de politique | Open Policy Agent | Policy-as-code pour les gates de delivery et les autorisations runtime. Le service ou gateway intégré doit appliquer les décisions ; les journaux de décisions soutiennent la traçabilité. | Oui - Apache-2.0 | https://www.openpolicyagent.org/ |
| Documentation humaine | Backstage TechDocs | Catalogue logiciel et docs-as-code destinés aux personnes, intégrés à l'ownership engineering. | Oui - Apache-2.0 | https://backstage.io/docs/features/techdocs/ |
| Contexte technique pour agents de programmation | Context7 | Documentation de bibliothèques et exemples de code adaptés à la version via MCP et CLI. Un exemple de diffusion du contexte technique, pas une plateforme complète de gouvernance de toutes les connaissances de l'entreprise. | Partiel - le serveur MCP est MIT ; le backend hosted est privé | https://context7.com/ |
| Exécution persistante des workflows | Temporal | Workflows persistants, reprise après panne et coordination des attentes et approbations. L'idempotence et la compensation des effets externes doivent toujours être conçues. | Oui - serveur MIT ; service cloud commercial | https://github.com/temporalio/temporal |
| Secrets et identifiants temporaires | OpenBao | Secrets centralisés, identifiants dynamiques pour les systèmes compatibles, expiration et révocation. Soutient l'accès au moindre privilège sans placer d'identifiants dans les prompts. | Oui - MPL-2.0 | https://github.com/openbao/openbao |
| Responsabilité et provenance des sources | OpenMetadata | Catalogue de métadonnées, responsables, signaux de qualité, lignage et analyse d'impact pour un contexte de données gouverné. Complète, sans remplacer, l'approbation des connaissances et les tests comportementaux. | Oui - projet Apache-2.0 | https://github.com/open-metadata/OpenMetadata |
Arize Phoenix: Arize Phoenix est une alternative pour le tracing, l'évaluation du retrieval, les expériences et le diagnostic comportemental. Il est source-available sous ELv2, pas open source approuvé par l'OSI. Licence.
LangGraph: LangGraph est un framework optionnel sous licence MIT pour les agents avec état, les checkpoints et la suspension/reprise pour revue humaine. Ce n'est pas une plateforme complète de gouvernance : l'interface de revue, la compétence des reviewers, les autorisations et les politiques d'approbation restent à mettre en œuvre.
Il s'agit d'exemples de capacités, pas d'un stack obligatoire ni d'une garantie de conformité ADLC. Sélectionner uniquement les composants nécessaires au périmètre approuvé et vérifier les licences et exigences opérationnelles de l'édition concernée.
LLM Gateway
Un LLM Gateway doit gouverner l'accès à plusieurs fournisseurs et orienter chaque tâche vers le modèle approuvé le plus adapté, selon la qualité évaluée, le risque, la latence, la disponibilité et le coût. L'équilibrage de charge ou le choix du modèle le moins cher ne suffit pas à démontrer son adéquation.
| Gateway / sources officielles | Licence / offre | Routage multi-fournisseurs | Contrôle des tokens et consommations |
|---|---|---|---|
| LiteLLM Documentation | Core open source : MIT ; modules enterprise sous licence séparée. | Stratégies coût/latence et fallbacks entre fournisseurs. | Cache et limites d'usage ; configurer paramètres de tokens de sortie et réduction éventuelle du contexte. |
| Portkey AI Gateway Documentation | Gateway open source : MIT ; offres hosted/enterprise séparées. | Routage multi-fournisseurs, équilibrage et fallback. | Cache ; optimisations avancées selon l'édition. Valider limites de sortie et politiques de contexte. |
| Kong AI Gateway Documentation | Fonctions AI avancées commerciales ; vérifier édition et licences des plugins. | Routage multi-fournisseurs et sémantique via plugins configurés. | Cache sémantique, limites tokens/coût ; compression avec un service supplémentaire. Configurer séparément les limites de sortie. |
| Cloudflare AI Gateway Documentation | Service géré propriétaire ; vérifier les limites du plan. | Routes conditionnelles, choix de modèles, fallbacks et budgets. | Cache et quotas de coût ; limites de génération selon les paramètres du fournisseur. Réduction du contexte à intégrer. |
Les gateways open source précèdent les services commerciaux. Ce sont des exemples, pas un stack obligatoire ni une recommandation commerciale. Aucune ligne ne garantit toutes les politiques entrée/sortie : vérifier version, compatibilité et édition, y compris streaming et budgets sous requêtes concurrentes.
Liens utiles
Références durables pour le risque enterprise, la responsabilité, la sécurité et la gouvernance du cycle de vie.
| Ressource | Description | Lien |
|---|---|---|
| NIST AI Risk Management Framework | Framework vendor-neutral pour gérer les risques et la fiabilité de l'AI durant la conception, le développement, le déploiement, l'utilisation et l'évaluation. | nist.gov/ai-rmf |
| NIST Generative AI Profile | Profil complémentaire qui applique l'AI RMF aux risques et contrôles du cycle de vie de l'AI générative. | nist.gov/genai-profile |
| ISO/IEC 42001 | Standard international pour les systèmes de management de l'AI, couvrant politiques, responsabilité, contrôles du risque et amélioration continue. Le standard complet est commercial. | iso.org/standard/42001 |
| MITRE ATLAS | Base de connaissances évolutive sur les tactiques et techniques adverses visant les systèmes AI, y compris les menaces agentiques et leurs mitigations. | atlas.mitre.org |
| OWASP Agentic AI Threats and Mitigations | Taxonomie fondée sur le threat modeling et recommandations de mitigation pour les systèmes AI autonomes et agentiques. | genai.owasp.org |
| OWASP State of Agentic AI Security and Governance | Rapport sur l'état actuel de la sécurité et de la gouvernance agentiques, utile comme lecture de contexte et non comme standard normatif. | genai.owasp.org/state-of-agentic-ai |
Spécifications ouvertes pour intégrer le contexte, assurer l'interopérabilité des agents et produire des preuves opérationnelles portables.
| Ressource | Description | Lien |
|---|---|---|
| Model Context Protocol | Protocole ouvert pour connecter les applications agentiques aux outils, sources de données et services de contexte gouvernés. | modelcontextprotocol.io |
| Agent2Agent Protocol | Standard ouvert Apache-2.0 pour la discovery, l'interaction sécurisée et la collaboration entre systèmes agentiques indépendants. | a2a-protocol.org |
| OpenTelemetry GenAI Semantic Conventions | Conventions Apache-2.0 pour des traces, métriques et événements portables couvrant retrieval, appels d'outils, MCP et exécution des agents. | github.com/open-telemetry/semantic-conventions-genai |
Ressources d'implémentation que les équipes doivent évaluer selon leurs contrôles, plateformes et modèles de risque.
| Ressource | Description | Lien |
|---|---|---|
| Microsoft APM | Dependency manager sous licence MIT pour distribuer des instructions, skills, plugins et serveurs MCP portables, versionnés et gouvernés par des politiques. | github.com/microsoft/apm |
| Superpowers | Framework open source de skills et méthodologie de delivery pour design, planification, TDD, revue et développement assisté par agents. | github.com/obra/superpowers |
| GitHub Copilot Token Optimization | Guide communautaire spécifique au produit pour réduire le contexte et la consommation de tokens sans compromettre la qualité de la delivery. | github.com/olivomarco/github-copilot-token-optimization |
| Terme | Nom complet / concept | Sens dans l'ADLC |
|---|---|---|
| ADLC | Agentic Development Lifecycle | Cycle de vie des systèmes agentiques, étendant le SDLC à la gouvernance du comportement, du contexte et de l'autonomie. |
| SDLC | Software Development Lifecycle | Discipline du cycle de vie logiciel, des exigences à la livraison, à l'exploitation et au retrait. |
| AI | Artificial Intelligence | Capacités d'intelligence artificielle utilisées dans le système, soumises aux mêmes contrôles de gouvernance. |
| LLM | Large Language Model | Modèle de langage utilisé par les agents ; sa version et sa configuration influencent le comportement et nécessitent une validation. |
| RAG | Retrieval-Augmented Generation | Récupération d'informations externes pour soutenir la génération ; optionnelle, avec sources gouvernées et tests de retrieval. |
| MCP | Model Context Protocol | Protocole reliant les applications AI aux outils et au contexte ; il ne remplace ni autorisation ni gouvernance. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | Intégration continue et livraison ou déploiement continu, avec contrôles obligatoires avant promotion. |
| IAM | Identity and Access Management | Gestion des identités et permissions, y compris les identités de service et la délégation limitée. |
| SSO | Single Sign-On | Authentification unique entre services ; elle n'autorise pas à elle seule l'exécution d'actions. |
| Human in the Loop | HITL | Revue humaine compétente et responsable aux étapes critiques, avec preuves et autorité d'intervention. |
| Quality gate | Quality gate | Contrôle d'entrée ou de promotion fondé sur des preuves ; le gate des exigences doit être validé avant l'implémentation. |
| Agent context | Agent context | Informations disponibles pour une tâche : instructions, sources récupérées, outils et mémoire. |
| Guardrail | Guardrail | Contrôle préventif ou de détection limitant les comportements dangereux ou non autorisés ; les limites critiques doivent être appliquées en runtime. |
| Orchestration | Orchestration | Coordination des agents, outils, états et workflows dans les permissions et budgets approuvés. |
| Context engineering | Context engineering | Sélection et composition du contexte opérationnel ; elle complète, sans la remplacer, la gouvernance de la connaissance. |