Premier agent IA : les garde-fous à poser avant de lui donner les clés

Premier agent IA : les garde-fous à poser avant de lui donner les clés

Le scénario des quatorze étapes

Reprenons le prototype d’achat construit pendant le week-end. Sa mission consiste à comparer trois offres, puis à préparer une recommandation vérifiable. Pour réussir, il doit accomplir quatorze actions obligatoires : formuler les requêtes, lancer les recherches, extraire les prix, uniformiser les devises et unités, calculer le classement, puis produire une synthèse accompagnée de ses sources.

Supposons que chaque action possède un taux de réussite de 95 %. Cette valeur est une hypothèse pédagogique, pas une mesure générale des agents. Si les quatorze opérations ont la même probabilité de succès et sont indépendantes, la probabilité d’obtenir une mission intégralement correcte se calcule par multiplication :

taux_unitaire = 0.95
nombre_etapes = 14
succes = taux_unitaire ** nombre_etapes
echec = 1 - succes
print(f'Succès : {succes:.1%}')
print(f'Échec : {echec:.1%}')

Le programme affiche 48,8 % de réussite et 51,2 % d’échec. Une opération fiable à 95 % paraît rassurante lorsqu’elle est examinée isolément. La mission complète échoue pourtant dès qu’une seule des quatorze validations est négative. Voilà l’écart entre fiabilité locale : la justesse d’une action, et fiabilité globale : la conformité du livrable entier.

Transformez maintenant ce calcul théorique en test du prototype. Après chaque retour du modèle ou d’un outil, ajoutez un booléen au journal d’exécution : True si le résultat respecte le critère prévu, False sinon. Le verdict final s’obtient avec all(etapes). Enregistrez aussi l’identifiant de l’essai, le numéro de la première défaillance et la sortie produite. Relancez dix fois le même dossier d’offres, sans modifier la consigne ni les données.

Comparez ensuite le taux de missions entièrement valides et la fréquence de réussite de chaque action. Deux essais identiques peuvent suivre des trajectoires différentes, car le comportement d’un agent reste en partie probabiliste d’une exécution à l’autre. Mesurez cette variabilité par le nombre de dossiers dont le verdict change entre deux répétitions : un succès isolé ne constitue pas une preuve de robustesse.

Ce que le calcul simplifie

La formule 0,95 ** 14 suppose d’abord des erreurs indépendantes. Cette condition est rarement parfaite. Une référence fournisseur mal reconnue peut provoquer une recherche inadéquate, une extraction portant sur le mauvais produit et, finalement, un classement erroné. Ces incidents forment une chaîne corrélée issue d’une cause commune ; les multiplier comme des événements autonomes donne alors une représentation imparfaite du risque.

Les anomalies n’ont pas davantage une gravité uniforme. Une ponctuation défectueuse dans la synthèse n’équivaut pas à une devise incorrecte qui inverse la recommandation. Ajoutez donc à chaque échec un niveau d’impact : mineur, révisable ou bloquant. Le taux global doit être lu avec cette distribution, sous peine de placer sur le même plan une retouche éditoriale et une décision d’achat fausse.

Les étapes présentent enfin des comportements distincts. Une calculatrice appelée avec des entrées valides fournit un résultat déterministe. Le choix d’une requête, l’interprétation d’une page ou la rédaction d’une conclusion restent probabilistes. Avec des taux propres à chaque opération, utilisez p1 × p2 × … × p14, toujours sous l’hypothèse d’indépendance.

Ce modèle ne prédit donc pas la fiabilité réelle du prototype. Il sert à révéler l’effet cumulatif des étapes et à orienter les essais. Conservez trois mesures : réussite intégrale, défauts classés par origine et gravité, désaccords entre répétitions. Les observations recueillies dans le journal doivent ensuite remplacer progressivement le taux arbitraire de 95 % par des fréquences mesurées sur vos propres cas métier.

Pourquoi un agent transforme une demande en longue chaîne d’actions

La boucle agentique, étape par étape

Un chatbot reçoit un message et rédige généralement une réponse. Un agent reçoit plutôt une mission dont il doit piloter l’exécution. Sa particularité tient à sa capacité à agir sur un environnement, observer les résultats, puis ajuster la suite. Une demande aussi brève que "trouve la meilleure offre et prépare la commande" devient donc un parcours composé de décisions et d’opérations.

1. Interpréter l’objectif. Le modèle détermine le résultat attendu, les contraintes explicites et les informations manquantes. "Meilleure offre" peut désigner le prix le plus bas, le délai le plus court ou le coût total livré.
2. Choisir l’action suivante. Il examine les outils disponibles, puis sélectionne celui qui semble pertinent. Le modèle joue ici le rôle de moteur de décision au sein d’une architecture associant modèle de langage, outils, mémoire et orchestration.
3. Exécuter l’action. L’orchestrateur transforme la décision en appel concret : lancer une recherche, interroger une base, lire un fichier ou transmettre des paramètres à une API.
4. Observer le résultat. La réponse du service (données, message d’erreur ou résultat vide) revient dans l’historique de travail. Elle devient une nouvelle pièce du dossier.
5. Adapter le plan. Le modèle décide s’il doit poursuivre, reformuler une requête, employer un autre outil ou conclure. Cette boucle se poursuit jusqu’à l’objectif ou jusqu’à une condition d’arrêt.

Pour suivre ce mécanisme pendant le tutoriel, représentez chaque tour par une fiche très courte : objectif courant → action choisie → paramètres → résultat → prochaine décision. Ce journal rend visible la transformation d’une consigne en chaîne opérationnelle.

Les composants qui allongent la chaîne

Chaque source consultée ajoute au moins un aller-retour. Une recherche web fournit des pages qu’il faut lire et extraire. Une base interne exige une requête, puis l’interprétation des enregistrements. Les capacités courantes couvrent également l’exécution de code, les API, les bases de données et les fichiers. Une mission mêlant ces ressources traverse donc plusieurs services, formats et vocabulaires métier.

Un outil n’est pas seulement une fonction technique. Il est présenté au modèle par un nom, une description et des paramètres typés. Cette notice constitue son mode d’emploi : le modèle lit la documentation pour comprendre l’usage de la fonction. Une description précise comme "rechercher un fournisseur par numéro SIREN" guide mieux qu’un intitulé flou tel que "recherche entreprise". Les paramètres doivent pareillement distinguer un identifiant, une date, une devise ou une quantité.

L’état persistant conserve l’avancement de la mission : fournisseurs déjà interrogés, références trouvées, montants collectés et action restant à accomplir. En parallèle, l’historique actif rassemble la consigne, les décisions et les retours d’outils. Cette mémoire immédiate reste bornée par une fenêtre de contexte donnée entre 128 000 et 1 million de jetons selon le modèle. Plus l’exécution avance, plus le modèle doit parcourir un dossier volumineux pour décider de l’étape suivante.

Un exemple métier déplié

Prenons une mission d’achat : "recommande 200 unités du produit X et prépare la commande". Son déroulement peut être matérialisé comme un carnet de mission en cinq blocs.

1. Collecte commerciale : rechercher les fournisseurs autorisés, récupérer leurs offres et relever prix, quantité minimale, disponibilité et délai.
2. Comparaison du marché : consulter des sources externes, harmoniser les désignations et ramener les montants à une même unité et à une même devise.
3. Consultation de l’ERP : appeler successivement les services consacrés au stock, aux contrats fournisseurs, aux remises négociées et au budget disponible.
4. Calcul de la recommandation : transmettre les valeurs normalisées à une calculatrice, intégrer transport et remises, puis classer les scénarios selon le critère métier retenu.
5. Préparation de la commande : assembler fournisseur, référence, quantité, prix, centre de coût et date souhaitée dans le format attendu par l’ERP.

La phrase initiale masque ainsi une succession de recherches, lectures, conversions, calculs et constructions de paramètres. L’agent n’exécute pas une réponse longue : il entretient un état, choisit une opération, appelle un service tiers et réinjecte son résultat dans la décision suivante.

Comment on lutte : une architecture de garde-fous, pas un bouton magique

Un garde-fou efficace ne cherche pas à rendre le modèle infaillible. Il réduit les occasions de faute, contrôle les transitions importantes et limite les conséquences lorsqu’une anomalie survient. L’architecture peut se construire en quatre temps : restreindre, borner, faire approuver, puis surveiller.

Avant l’exécution : réduire le périmètre

Commencez par transformer la mission en objectif étroit et mesurable : "produire un tableau conforme à cinq champs obligatoires à partir de trois sources autorisées" est vérifiable ; "analyser le marché" ne l’est pas. Découpez ensuite le travail en tâches courtes, chacune assortie d’une entrée attendue, d’un résultat contrôlable et d’un motif d’échec explicite.

• Réduisez la boîte à outils. Appliquez le principe du moindre privilège : un agent chargé de consulter des données n’a besoin ni d’expédier des courriels, ni d’écrire dans une base, ni d’effectuer des achats.
• Fermez les permissions par défaut. Accordez les accès ressource par ressource, pour une durée et un environnement déterminés. Séparez les identifiants de test de ceux de production.
• Imposez un contrat de sortie. Définissez les champs, types, valeurs admissibles et règles métier. La validation des sorties structurées intercepte une réponse mal formée avant qu’elle n’alimente la suite du traitement.
• Préparez un banc d’essai. Réunissez des cas ordinaires, incomplets, ambigus et volontairement invalides. Le résultat attendu et les critères d’acceptation doivent être écrits avant le premier test.

Pendant l’exécution : borner et vérifier

La boucle doit savoir quand elle a terminé. Inscrivez une condition d’arrêt calculable : résultat validé, information déclarée introuvable, demande refusée ou seuil atteint. Ajoutez un délai maximal et un plafond de dix à vingt-cinq étapes, fourchette adaptée à la plupart des missions selon les sources. Cette limite est un fusible, non un objectif à atteindre.

Fixez aussi un budget par exécution : coût cumulé des appels au modèle, nombre de requêtes d’outils et, si nécessaire, quota quotidien. Un plafond de dépense prévient les factures incontrôlées lorsqu’une boucle se dérègle. À chaque tour, l’orchestrateur doit vérifier les trois compteurs ( étapes, temps, coût ) avant d’autoriser l’action suivante.

Encadrez chaque outil par une gestion d’exception. En cas d’indisponibilité, de délai dépassé ou de réponse invalide, l’erreur peut être transmise au modèle pour choisir une autre voie. Cette auto-correction reste bornée : un ou deux nouveaux essais, uniquement pour les erreurs temporaires ou de format, puis arrêt ou escalade. Ne relancez jamais automatiquement une opération dont l’état d’exécution demeure incertain.

Placez enfin des points de contrôle après les tâches déterminantes. Sauvegardez l’état validé, pas seulement le texte produit, afin de reprendre depuis une étape saine. Des orchestrateurs comme LangGraph proposent une gestion explicite de l’état, des checkpoints et des embranchements, utile pour isoler les reprises et empêcher le parcours improvisé d’un scénario sensible.

Avant une action irréversible : rendre la main

Une action sensible doit d’abord devenir un brouillon. Présentez à l’opérateur une fiche concise indiquant la cible, les données utilisées, l’effet attendu, le montant ou le volume concerné et les éléments modifiés. L’approbation doit porter sur cette action précise, et non sur une autorisation générale accordée au début de la session.

Exigez une validation humaine avant l’écriture d’un fichier ou l’envoi d’un courriel. Appliquez le même contrôle aux suppressions, paiements, publications, changements de droits et mises à jour de données métier. La personne doit pouvoir approuver, corriger ou refuser sans interrompre tout le dossier.

Séparez techniquement lecture et écriture : l’agent prépare avec un accès consultatif, puis un composant distinct exécute après approbation. Conservez l’identité de l’approbateur, l’horodatage, le contenu présenté et la décision. Cette trace interdit qu’une validation ancienne soit réutilisée pour une action modifiée.

Après l’exécution : rendre l’agent observable

Attribuez un identifiant à chaque exécution et journalisez chaque appel au modèle comme aux outils. Les traces doivent réunir les entrées, les sorties et les horodatages de chaque appel, ainsi que sa durée, son statut, son coût et la version de la configuration. Masquez les secrets et limitez les données personnelles conservées.

Testez le comportement complet, pas uniquement le livrable. Les évaluations automatisées des agents de production doivent vérifier le choix des outils, le respect des plafonds, le refus des permissions interdites, la sollicitation d’une approbation et l’arrêt sur incident. Rejouez ces scénarios après toute modification du modèle, des instructions, des outils ou des règles métier.

Prévoyez une réponse dégradée contrôlée : produire un brouillon incomplet signalé, passer en lecture seule, transférer au processus manuel ou suspendre la mission. Pour un agent planifié ou doté de capacités à fort enjeu, installez un coupe-circuit activable sans redéploiement. Testez-le réellement.

Enfin, désignez un responsable joignable et formalisez la procédure d’incident : critères d’alerte, arrêt, préservation des traces, analyse, correction et conditions de remise en service. Le dossier ne fournit pas de cadre juridique suffisamment solide pour détailler les obligations liées au RGPD, à l’AI Act ou à la répartition contractuelle des responsabilités ; ces points exigent une analyse juridique adaptée au contexte, aux données et aux usages concernés.

L’effet boule de neige : quand une petite erreur change toute la suite

Une erreur intermédiaire ne reste pas confinée à l’étape qui l’a produite. Inscrite dans l’état courant, elle devient une nouvelle entrée que l’agent tient pour acquise. Elle influence alors son plan, s’accumule dans sa mémoire active et détermine les paramètres transmis aux outils suivants. La réponse finale peut demeurer fluide, argumentée et vraisemblable alors que l’action préparée repose sur une prémisse fausse.

Les quatre chemins de propagation

Premier chemin : la donnée source mal interprétée. Une remise de 12 % est extraite comme un prix de 12 euros. Cette valeur rejoint le contexte sans indication d’incertitude ; l’agent réorganise ensuite son raisonnement autour d’elle. La sortie défectueuse d’une étape devient ainsi l’entrée apparemment légitime de la suivante.

Deuxième chemin : le mauvais outil ou le mauvais paramètre. L’agent interroge une page grand public au lieu du catalogue professionnel, recherche une référence incomplète ou transmet une devise incorrecte à la calculatrice. Si l’appel échoue explicitement, l’erreur reste souvent récupérable : il est recommandé d’intercepter l’exception et de la réinjecter dans le contexte, afin que le modèle puisse reformuler sa requête ou choisir une autre voie. Un résultat techniquement valide mais sémantiquement faux est plus dangereux, car aucun échec logiciel ne le signale.

Troisième chemin : le résultat obsolète. Un ancien tarif demeure dans la mémoire active après une recherche plus récente. L’agent peut citer la nouvelle page tout en calculant avec l’ancienne valeur. Sur les exécutions longues, la synthèse des anciens retours d’outils limite l’encombrement du contexte, mais cette compression doit préserver la date, la provenance et le statut de validité.

Quatrième chemin : la correction locale incohérente. Le prix est rectifié dans le tableau, mais pas dans la marge déjà calculée ni dans la recommandation rédigée. Plusieurs versions d’un même fait coexistent alors. Une validation uniquement finale arrive trop tard : elle examine un livrable propre sans nécessairement reconstruire son historique.

Du prix erroné à la mauvaise commande

Prenons un agent chargé d’étudier les ventes, de relever les prix concurrents, de consulter l’ERP puis de préparer un réapprovisionnement. Ce type d’enchaînement correspond à un exemple d’agent coordonnant données commerciales, Web, ERP et commande soumise à approbation.

1. La page affiche 89,90 euros hors taxes, mais l’extracteur retient 69,90 euros, montant réservé aux adhérents.
2. La calculatrice reçoit ce prix sans son statut tarifaire et produit une marge artificiellement faible.
3. L’agent recommande une baisse commerciale pour rester compétitif.
4. Cette décision modifie les prévisions de vente, puis la quantité inscrite dans le brouillon de commande ERP.
5. Le résultat paraît cohérent : chiffres, justification et quantité concordent, précisément parce qu’ils dérivent tous de la même erreur.

À ce stade, une approbation humaine avant soumission peut encore interrompre la chaîne en comparant le prix retenu à sa source. Après paiement, publication ou engagement contractuel, la récupération devient coûteuse, voire impossible. Si l’agent a épuisé ses tentatives, son budget ou son nombre d’étapes, une réponse dégradée et maîtrisée doit remplacer l’exception brute : par exemple, conserver la commande en brouillon et signaler le champ non vérifié.

L’analogie de la course de relais

Imaginez chaque étape comme un relayeur. Le témoin transmis n’est pas seulement une donnée : il contient aussi sa provenance, son ancienneté, son unité et les hypothèses retenues. Si un coureur le déforme, les suivants peuvent exécuter parfaitement leur portion tout en éloignant l’équipe du bon résultat. Des contrôles placés entre certains relais permettent de vérifier les éléments qui gouvernent la suite : référence produit, devise, prix, marge ou quantité.

L’image reste toutefois imparfaite. Une course suit une trajectoire linéaire ; un agent peut revenir en arrière, appeler plusieurs outils, résumer sa mémoire ou choisir une branche différente selon une observation. Une erreur peut donc se diffuser, être corrigée partiellement, puis réapparaître depuis un ancien résultat. Le dossier fournit des exemples de workflows, mais aucune donnée indépendante permettant de mesurer la fréquence réelle de chaque mode de propagation. Il faut donc les rechercher dans les traces d’exécution plutôt que leur attribuer une probabilité supposée.

Ce que cela révèle de la maturité réelle des agents IA

Pourquoi une démo convaincante ne suffit pas

Un prototype peut naître en un week-end : la boucle élémentaire tient dans moins de 100 lignes de Python, et les API d’OpenAI comme d’Anthropic gèrent nativement les appels d’outils. Cette facilité mesure la vitesse d’assemblage, non la solidité du système. Une démonstration repose souvent sur un scénario préparé, des données propres et une interface soignée, alors que le moteur devra ensuite affronter des champs absents, des formats inattendus, des services indisponibles ou des demandes ambiguës.

Une exécution réussie masque aussi la variabilité : elle ne montre ni les tentatives infructueuses ni les cas limites écartés pendant la préparation. L’évaluation doit donc porter sur un lot représentatif, rejoué plusieurs fois, puis sur des situations dégradées. La comparaison entre démonstration et production gagnerait à être étayée par des benchmarks indépendants et des retours d’incident documentés.

Les dépenses invisibles à l’écran augmentent avec la longueur du parcours. Cinq à dix appels d’outils sont estimés entre 0,01 et 0,05 dollar par exécution, dix étapes entre 0,05 et 0,25 dollar, tandis qu’un agent dépassant cinquante appels peut atteindre 1 à 5 dollars. Une seule mission peut en outre mobiliser 3 000 à 10 000 jetons. Il faut ajouter la supervision, les tests, la maintenance des connecteurs et le traitement des échecs. Une prévision attribuée à Gartner indique d’ailleurs que plus de 40 % des projets agentiques pourraient être abandonnés avant fin 2027, notamment pour dérive budgétaire et défaut d’encadrement.

Une échelle d’autonomie raisonnable

Pour évaluer un agent, mieux vaut déterminer quelles erreurs peuvent être repérées, corrigées et assumées que vérifier s’il "fonctionne". Une matrice risque-autonomie fournit une règle de décision simple :

• Risque faible : lecture seule, synthèses et recommandations sans effet externe.
• Risque modéré : brouillons de courriels, rapports ou requêtes soumis à validation.
• Risque limité et réversible : actions automatiques sous plafond de montant, de volume, de durée ou de périmètre.
• Risque élevé : approbation obligatoire avant paiement, suppression, publication ou modification de droits.
• Risque incontrôlable : exclusion de l’agent lorsque les conséquences sont irréversibles, indétectables ou incompatibles avec les obligations métier.

Le déploiement suit cette échelle : observation silencieuse, mode brouillon, accès à un petit groupe, puis extension graduelle. Chaque palier doit rester réversible, avec retour immédiat au processus manuel si les résultats, les délais ou les dépenses franchissent le seuil convenu.

Le récapitulatif avant de donner les clés

Avant l’ouverture, consignez ces six points dans une fiche d’autorisation courte, datée et validée :

1. Mission : tâche circonscrite et critères mesurables de réussite, d’échec et de qualité.
2. Accès : permissions, données et outils strictement nécessaires.
3. Plafonds : nombre d’étapes, appels, coût, durée et volume quotidien bornés.
4. Contrôles : validation explicite aux moments critiques.
5. Observabilité : journaux exploitables, tests représentatifs et alertes sur erreurs, latence et dépenses.
6. Responsabilité : arrêt immédiat testé, reprise manuelle disponible et responsable humain nommé.

Si l’un de ces éléments manque, réduisez l’autonomie d’un cran plutôt que de compenser par une confiance implicite.

Sources

1. How to Build AI Agents in 2026: A Beginner's Complete Tutorial — uselearnai.com

2. How to Build an AI Agent from Scratch [2026] (Step-by-Step) — precisionaiacademy.com

3. Comment créer un agent IA : le guide pratique pour débutants en 2026 — ai-explorer.io

4. Google's New Managed Agent API (Antigravity Agent) in Plain English — youtube.com