Solution · AI Operations

Tous tes agents d'IA ont une date d'allumage. Presque aucun n'a de date de revue ni d'extinction.

Construire un agent, c'est un projet. Ce que presque personne n'a construit, c'est la fonction qui le gouverne ensuite : un catalogue où chaque agent a un propriétaire et une version, une porte qui décide quel changement atteint la production, un rollback qui marche, une revue qui vérifie s'il rapporte encore, et une vraie mise hors service — identifiants révoqués. On construit ce cycle de vie et on l'exploite.

On le monte chez moi Voir comment ça marche

Le problème

L'agent numéro un, tout le monde s'en souvient. Le numéro quatorze, personne ne sait qui l'a demandé, quelle version tourne, ni si quelqu'un l'utilise.

Personne n'a la liste. Il n'existe pas d'endroit où figurent tous les agents qui tournent aujourd'hui avec leur propriétaire, leur version, leurs permissions et la raison de leur validation : il y a un tableur périmé et la mémoire de trois personnes.
Un changement de prompt arrive en production parce que quelqu'un y a touché, pas parce qu'il a passé une porte : pas d'environnement de test, pas d'évaluation qui le compare à la version précédente, et aucun moyen propre de revenir en arrière s'il est pire.
« Version » veut dire des choses différentes selon la personne : le modèle a changé tout seul, le prompt a été édité à la main et les outils connectés ne sont plus ceux d'il y a trois mois — et rien de tout ça n'est rattaché à un numéro que tu peux nommer.
Il y a des agents que plus personne n'utilise et qui restent allumés : ils consomment des tokens tous les jours et maintiennent vivants des identifiants avec droits d'écriture, et personne ne les éteint parce que personne n'est sûr de ce qui casse.
Quand quelqu'un demande si un agent rapporte encore, la réponse est une opinion : pas de référence de départ, pas de cadence de revue, pas de critère écrit disant quand on le refait et quand on le retire.

Le coût de ne rien changer

Gartner a prédit, dans son communiqué du 25 juin 2025, que plus de 40 % des projets d'IA agentique seront annulés avant la fin 2027 — et les raisons avancées ne sont pas techniques : coûts qui grimpent, valeur métier peu claire, contrôles du risque insuffisants. Les trois se pilotent dans le cycle de vie ou ne se pilotent nulle part. Et le trou est mesuré : dans le livre blanc « The Non-Human Identity Governance Vacuum » de la Cloud Security Alliance (mai 2026), 78 % des organisations déclarent n'avoir aucune politique documentée pour créer et supprimer des identités d'IA, 51 % n'ont pas de propriétaire clair pour ces identités, et seules 20 % disposent d'un processus formel de sortie avec révocation des clés. Traduit chez toi : chaque agent que tu allumes sans cycle de vie, c'est du coût que personne ne réexamine et un identifiant que personne ne révoquera. Ça ne casse pas le jour un. Ça s'accumule.

La solution

On construit le cycle de vie de tes agents — catalogue, porte de promotion, versionnage avec rollback, revue et mise hors service — et on l'exploite comme fonction continue

1On dresse le vrai catalogue, pas celui que tu crois avoir : quels agents tournent aujourd'hui, qui les a demandés, qui en répond, quelle version est vivante, avec quelles permissions et quel identifiant. Il en sort presque toujours que personne ne se souvenait d'avoir allumés.
2On met des états et des portes. Un agent passe de proposé à validé, de validé à production et de production à retiré par un chemin écrit, pas parce que quelqu'un l'a déployé un jeudi. Avant la production il y a une évaluation sur des cas réels de ton métier, et c'est cette évaluation qui ouvre la porte — pas l'impression que ça marche.
3On fait en sorte que « version » veuille dire quelque chose : prompt, modèle, outils connectés et limites sont rattachés à une version nommée, comparable à la précédente et réversible en quelques minutes. C'est ce que font déjà les plateformes sérieuses — AWS Bedrock AgentCore fige chaque mise à jour en version immuable et revient en arrière en repointant l'endpoint ; Microsoft Foundry conserve des snapshots d'agent et promeut entre environnements avec des portes fondées sur des évaluations — et on le construit sur ce que tu utilises déjà plutôt que de t'amener un outil de plus.
4On ajoute la revue périodique, là où se décide si un agent reste vivant : combien il coûte, combien il est utilisé, avec quelle qualité il répond par rapport à sa référence, et si le processus qu'il servait existe encore. Avec un critère écrit disant quand on l'ajuste, quand on le refait et quand on le retire — pour que la décision ne dépende pas de qui est dans la salle.
5On ferme par la fin, la pièce que presque personne n'a construite : la mise hors service. On éteint l'agent, on révoque ses identifiants et ses accès, on décide ce qu'on garde de ses journaux et pour combien de temps, et on transfère ce qu'il faisait. C'est l'étape de retrait qu'un système de management de l'IA comme l'ISO/IEC 42001 impose de traiter explicitement — et, au passage, celle qui arrête de payer pour des agents que plus personne n'utilise.

Ce qui change

Ce que tu arrêtes de perdre

Le catalogue cesse d'être un tableur périmé : chaque agent vivant a un propriétaire, une version, des permissions et la raison de sa validation — et ce qui n'est pas au catalogue ne tourne pas.
Mécanisme
Un mauvais changement cesse d'être une affaire d'heures : la version précédente a un nom et on y revient, au lieu de reconstruire à la main le prompt du mardi.
Mécanisme
L'agent que plus personne n'utilise cesse d'être une dépense invisible et un identifiant ouvert : la revue le détecte et la mise hors service le ferme pour de bon, accès révoqués.
Mécanisme
Ce qu'on mesure : % d'agents vivants avec propriétaire et version au catalogue, % de changements passés en production par la porte d'évaluation, temps de rollback vers la version précédente, agents revus et retirés par trimestre, et identifiants révoqués après chaque sortie.
Ce qu'on mesure

Fiche technique

Travail supprimé: découvrir trop tard quels agents tournent, qui les a demandés et quelle version est vivante — et ne pas pouvoir revenir en arrière quand un changement tourne mal ni éteindre vraiment celui que plus personne n'utilise
Mise en place habituelle: 4 à 8 semaines
Entrée: les agents que tu as déjà en fonctionnement, avec leurs prompts, leurs modèles, leurs outils connectés et leurs identifiants
Sortie: un catalogue vivant avec propriétaire, version et état par agent, une porte de promotion avec évaluation, un rollback vers la version précédente, une revue périodique à critère écrit et une mise hors service qui révoque les accès
Compatible avec: AWS Bedrock AgentCoreMicrosoft Foundry Agent ServiceGoogle Vertex AI Agent EngineLangSmithLangGraphn8nOpenAIAnthropic
Peut se connecter à: Ton gestionnaire de versions et ton CITon coffre à secrets et ton fournisseur d'identitéTa batterie d'évaluation sur des cas réels du métierTon inventaire d'identités non humaines, si tu en tiens un
Ce qu’on mesure: % d'agents vivants avec propriétaire et version au catalogue% de changements promus par la porte d'évaluationtemps de rollback vers la version précédenteagents revus et retirés par trimestreidentifiants révoqués après chaque sortie
Adapté pour: des entreprises passées du premier agent au dixième et qui commencent à ne plus savoir combien elles en ont, qui répond de chacun, ni lesquels pourraient être éteints sans que ça se voie
Pas adapté pour: celui qui a un seul agent en production et une personne qui le connaît de bout en bout : là, le cycle de vie est une conversation, pas une fonction

Questions fréquentes

Par l'objet. Maintenir répond à « que mes agents continuent de bien tourner » : surveiller la dérive, mettre à jour quand un modèle change, contrôler le coût, réagir quand ça se dégrade. Tu as ça développé dans qui maintient les agents d'IA en production, et répondre à une panne précise, c'est la gestion des incidents. Le cycle de vie répond à autre chose : quels états traverse un agent et qui autorise chaque saut. Entrée avec propriétaire et motif, validation avant production, promotion par une porte d'évaluation, versions nommées avec rollback, revue à cadence et retrait avec révocation. Maintenir est le verbe du quotidien ; le cycle de vie est le cadre qui décide ce qui entre, ce qui change et ce qui sort. Sans lui, maintenir finit par entretenir des choses que plus personne ne devrait avoir allumées.

Elle te donne le mécanisme, pas la fonction, et c'est cette différence qui se paie. AWS Bedrock AgentCore versionne de façon immuable et permet de revenir en arrière ; Microsoft Foundry conserve des snapshots et permet de poser des portes d'évaluation entre environnements. Parfait : on les utilise. Ce qu'aucune plateforme ne te donne, c'est qui répond de chaque agent, quelle évaluation un changement doit passer pour être acceptable dans TON métier, à quelle fréquence on vérifie qu'un agent rapporte encore, sur quel critère on décide de le retirer, ni ce qu'on fait de ses identifiants et de ses journaux le jour où on l'éteint. Ce sont des décisions et des cadences, et il faut les exploiter. Et si tes agents sont répartis entre plusieurs plateformes — la norme dès le troisième —, le catalogue et le critère doivent vivre au-dessus de toutes.

L'éteindre est la partie facile et la moins importante. Retirer vraiment, c'est révoquer ses identifiants et ses permissions — là où presque tout le monde échoue : seules 20 % des organisations disent avoir un processus formel de sortie avec révocation des clés, selon le livre blanc de la Cloud Security Alliance de mai 2026 —, décider quels journaux on conserve et combien de temps, prévenir ceux qui en dépendaient et transférer ce qu'il faisait. Un agent « éteint » dont l'identité est toujours vivante n'est pas un agent retiré : c'est un identifiant avec droits d'écriture que plus personne ne surveille parce que, officiellement, cet agent n'existe pas. C'est pour ça que le retrait est une étape du cycle de vie avec liste de contrôle, pas un interrupteur.

On le monte chez toi ?

Tu as ciblé le problème. On livre la solution et on la laisse mesurée.

Voir le service