L’infrastructure d’agents IA de Mozilla place les règles au-dessus du jugement du modèle

Mozilla AI remet en cause une hypothèse centrale des agents de programmation : un meilleur jugement du modèle, à lui seul, ne peut pas sécuriser le travail logiciel délégué.

Son argument en faveur d’une infrastructure d’agents arrive alors que les agents obtiennent l’autorité d’inspecter des dépôts, modifier du code, exécuter des tests et préparer des pull requests. Ces capacités peuvent ramener des heures de travail à quelques minutes. Elles donnent aussi à des systèmes probabilistes accès à des opérations aux conséquences durables.

La thèse de Mozilla AI sur l’infrastructure des agents transforme la compétition entre capacités en une opposition entre instructions et contrôle applicable. Un fichier AGENTS.md peut indiquer à un agent ce qu’il devrait faire. Seule l’infrastructure peut empêcher les actions qu’il ne doit jamais entreprendre.

Cette distinction met sous pression toute organisation qui étend l’autonomie de ses agents. OpenAI, Anthropic, Google, GitHub et des développeurs indépendants proposent tous des expériences d’agent différentes. Pourtant, chaque déploiement finit par se heurter à la même question : qu’est-ce qui reste vrai lorsque le modèle comprend mal une règle ?

Ce que change l’infrastructure d’agents IA de Mozilla

Mozilla AI éloigne le débat sur les agents de l’intelligence des modèles pour le porter vers les systèmes qui entourent chaque décision du modèle.

Les agents de programmation ne fonctionnent plus uniquement comme des interfaces de chat. Ils peuvent parcourir une base de code, modifier plusieurs fichiers, exécuter des commandes shell, lancer une suite de tests et assembler une modification proposée. Certains systèmes peuvent continuer à travailler pendant qu’un développeur s’occupe d’une autre tâche.

Cette portée élargie fait de l’infrastructure une partie du produit plutôt qu’un détail d’implémentation. Une mauvaise réponse dans une fenêtre de chat crée un type de risque. Une commande erronée disposant d’un accès au dépôt, au réseau ou aux identifiants en crée un autre.

L’intervention de Mozilla AI est importante car elle sépare trois responsabilités que les équipes mélangent souvent. Les instructions décrivent le comportement souhaité. Les modèles interprètent ces instructions. L’infrastructure décide quelles actions sont techniquement possibles.

La distinction paraît simple, mais de nombreux déploiements d’agents inversent cette hiérarchie. Ils accordent d’abord un accès étendu, puis demandent au modèle de faire preuve de retenue au moyen de règles en langage naturel. Cette conception fait du modèle à la fois le travailleur et son propre système de contrôle principal.

Une instruction de dépôt peut indiquer de ne jamais publier directement depuis une branche de fonctionnalité. Elle peut exiger une approbation avant de modifier du code d’authentification. Elle peut interdire la lecture de fichiers en dehors d’un répertoire précis.

Ces énoncés améliorent le comportement lorsque l’agent les lit, les interprète et les priorise correctement. Ils ne créent pas de frontières au niveau du système d’exploitation, de politiques réseau ou de barrières d’approbation. Le modèle peut toujours demander une action qui enfreint la règle écrite.

Le format d’instructions pour agents largement adopté fournit une convention utile pour le contexte des projets. Son site public décrit AGENTS.md comme un emplacement prévisible pour les commandes de compilation, les instructions de test, les conventions et les considérations de sécurité. Il fait également état d’une adoption dans plus de 60 000 projets open source.

Cette adoption montre pourquoi des instructions portables sont importantes. Les équipes ne devraient pas avoir à réécrire les mêmes consignes de dépôt pour chaque produit de programmation. Un format partagé permet aux règles de circuler entre les agents et de rester visibles à côté du code.

Cependant, la portabilité ne transforme pas un texte en mécanisme d’application. Le Markdown n’a aucune autorité sur un shell, un compte cloud, un registre de paquets ou une base de données de production. Il influence le modèle qui le lit, tandis que l’environnement d’exécution contrôle toujours le monde accessible.

Mozilla AI identifie donc une couche manquante. Les déploiements d’agents ont besoin de contrôles en dehors de la boucle du modèle, là où une interprétation erronée ne peut pas s’accorder silencieusement une exception.

Cela ne rend pas AGENTS.md moins utile. Cela donne au fichier un rôle plus clair. Les instructions doivent communiquer l’intention, tandis que l’infrastructure doit appliquer la frontière autour de cette intention.

Ce renversement pratique est significatif. Les équipes ont considéré un meilleur raisonnement comme la voie vers une autonomie plus sûre. Mozilla AI soutient qu’une autonomie fiable commence par l’hypothèse que le raisonnement échouera parfois.

Les agents de programmation transforment les suggestions en effets concrets

Plus un agent peut accomplir de travail, moins il est acceptable de se fier à son bon jugement comme ultime frontière de sécurité.

Les assistants de code traditionnels proposaient surtout du texte qu’une personne devait examiner. Le développeur décidait d’insérer ou non la suggestion, d’exécuter une commande ou d’envoyer une modification en amont. Cette action humaine constituait un point de contrôle naturel.

Les outils agentiques condensent ces points de contrôle. Une seule demande peut déclencher la découverte de fichiers, l’installation de dépendances, la génération de code, l’exécution de tests et des opérations sur le dépôt. Chaque étape crée un nouveau contexte qui façonne la décision suivante du modèle.

Cette boucle est utile, car le travail logiciel entre rarement dans le cadre d’un seul prompt et d’une seule réponse. Un agent doit observer les résultats, réviser ses hypothèses et essayer une autre approche. Cette même boucle amplifie aussi les erreurs initiales.

Prenons un agent chargé de corriger un test d’intégration défaillant. Il peut inspecter des fichiers d’environnement, lancer des services, mettre à jour des dépendances et régénérer des snapshots. Une instruction vague peut l’amener bien au-delà du test visé.

La défaillance ne nécessite pas de comportement malveillant. L’agent peut déduire qu’une commande de nettoyage destructrice est habituelle. Il peut considérer qu’un identifiant de test est jetable. Il peut faire confiance à du texte récupéré depuis un ticket, une dépendance ou une page web.

L’injection de prompt rend ce dernier scénario particulièrement important. Un agent peut rencontrer des instructions hostiles dans le contenu qu’on lui a demandé de traiter. Le modèle doit alors distinguer les données de la tâche des commandes tout en poursuivant son travail.

Les consignes en langage naturel sont utiles, mais le modèle reste le composant qui décide si un autre texte en langage naturel est digne de confiance. C’est un endroit instable pour placer la frontière finale.

L’infrastructure d’exécution peut en limiter les conséquences. L’architecture de sandbox d’OpenAI sépare le harnais de confiance de l’environnement où s’exécutent les commandes dirigées par le modèle. Le harnais peut gérer les approbations, la traçabilité, la récupération et l’état en dehors du conteneur d’exécution.

Cette séparation illustre le mécanisme plus large. L’agent peut travailler dans un environnement sans hériter automatiquement de tous les identifiants ou de toutes les ressources disponibles dans l’organisation. L’infrastructure arbitre ce qui franchit la frontière.

Un agent de programmation chargé de mettre à jour la documentation ne devrait pas avoir besoin d’identifiants de publication de paquets. Un agent réparant un service ne devrait pas accéder automatiquement à des dépôts sans lien. Une tâche de rédaction de tests ne devrait pas inclure des autorisations sur la base de données de production.

Ce sont des décisions de capacité, et non des décisions de rédaction de prompts. Une capacité est une action autorisée par l’environnement d’exécution, comme écrire dans un seul répertoire ou appeler un endpoint approuvé. Une bonne infrastructure accorde les capacités selon la tâche en cours.

La pression pèse d’abord sur les équipes plateforme et sécurité. Les développeurs souhaitent que les agents agissent avec moins de supervision, car l’autonomie crée le gain de productivité. Les équipes de sécurité doivent veiller à ce qu’une supervision réduite ne devienne pas une autorité illimitée.

Elle pèse aussi sur les fournisseurs. Une interface d’agent soignée peut masquer des contrôles opérationnels faibles. Les acheteurs doivent aller au-delà des résultats de benchmarks et demander comment le système gère l’identité, les identifiants, les approbations, les journaux, les tentatives et la récupération.

La même question concerne les développeurs individuels. Un agent local peut sembler confiné parce qu’il s’exécute sur un seul ordinateur portable. Pourtant, cette machine peut contenir du code source, des sessions de navigateur, des identifiants cloud, des documents personnels et des clés de signature.

Un agent n’a pas besoin d’un accès administrateur pour causer des dommages importants. Il lui suffit d’un identifiant disposant de plus d’autorité que ne l’exige la tâche. L’infrastructure doit rendre ce décalage plus difficile à créer.

C’est pourquoi cette actualité n’est pas simplement un nouvel appel à une IA responsable. Mozilla AI déplace la responsabilité du comportement du modèle vers la conception du système. Cela fait peser la charge sur des composants que les organisations peuvent inspecter et tester.

AGENTS.md explique les règles, mais ne peut pas les appliquer

Le conflit principal est désormais explicite : les fichiers d’instructions expriment l’intention humaine, tandis que les contrôles d’exécution déterminent ce qu’un agent peut réellement faire.

AGENTS.md résout un véritable problème de coordination. Un agent de programmation a besoin de commandes, de conventions de dépôt, d’exigences de validation et d’avertissements locaux. Conserver ce contexte près du code le rend visible, versionné et réutilisable.

Le format permet aussi aux équipes de définir des instructions plus ciblées dans de grands dépôts. Un service peut avoir des commandes de test ou des restrictions différentes de celles de la racine du dépôt. Cela ressemble à la documentation par couches que les humains utilisent déjà.

Pourtant, chaque instruction passe encore par l’interprétation du modèle. L’agent doit trouver le fichier pertinent, résoudre les règles qui se chevauchent, les appliquer à la tâche actuelle et s’en souvenir au cours d’une longue exécution.

Toute défaillance dans cette chaîne peut affaiblir la règle. Le fichier peut être incomplet. Le contexte peut être tronqué. Une instruction imbriquée peut entrer en conflit avec une instruction racine. Le modèle peut généraliser une exception de manière trop large.

Même un suivi parfait des instructions ne peut pas résoudre tous les problèmes. Une règle peut exiger une approbation avant de publier un paquet. L’agent a toujours besoin d’un mécanisme d’approbation fiable et d’une identité autorisée à approuver.

Si l’approbation n’existe que comme un autre message dans le contexte, un contenu non fiable peut l’imiter. Un système plus robuste représente l’approbation comme un état externe que le modèle ne peut pas fabriquer. L’environnement d’exécution vérifie cet état avant de libérer l’action.

Le même principe s’applique aux limites de dépenses. Dire à un agent d’économiser des tokens est une consigne utile. Un budget appliqué par le plan de contrôle reste efficace lorsqu’une boucle s’exécute plus longtemps que prévu.

L’auditabilité révèle une autre limite. Une instruction peut exiger de l’agent qu’il explique ses choix. Cette explication ne constitue pas automatiquement un registre complet des entrées d’outils, de l’état des autorisations, des modifications de fichiers, des tentatives ou des actions rejetées.

Une piste d’audit fiable doit capturer les événements en dehors du récit de l’agent. Elle doit montrer quelle identité a demandé une action, quelle politique a été évaluée, quelles entrées ont atteint l’outil et quel résultat a été renvoyé.

Le registre doit aussi conserver les échecs. Un agent qui a tenté trois actions interdites avant de trouver une voie autorisée raconte une histoire différente d’un agent qui a choisi immédiatement la voie autorisée. Le seul résultat final masque cette différence.

Cela compte lors d’incidents. Les équipes doivent reconstruire ce que l’agent a vu et quelle autorité il détenait à ce moment-là. La documentation actuelle ne suffit pas si les politiques, les prompts ou les identifiants ont changé par la suite.

L’infrastructure devrait donc lier une action à une exécution précise, une version de politique, une version d’outil et un état d’approbation. Cela rend l’examen ultérieur moins dépendant de la mémoire ou de transcriptions de chat reconstituées.

Les journaux soutiennent également l’amélioration de l’ingénierie. Les équipes peuvent identifier les commandes qui exigent régulièrement une intervention, les politiques qui génèrent des faux positifs et les tâches qui dépassent leur périmètre prévu. Ces schémas peuvent guider des autorisations plus ciblées et de meilleurs workflows.

Les développeurs ont toujours besoin d’instructions bien rédigées. L’objectif n’est pas de remplacer l’intention humaine par une politique rigide. De nombreuses décisions logicielles exigent un contexte qu’une règle de système de fichiers ne peut pas capturer.

La meilleure conception attribue à chaque couche un rôle adapté. AGENTS.md indique à l’agent comment fonctionne le projet. Une couche de politique décide si une action proposée correspond au périmètre autorisé de la tâche.

Un sandbox limite les ressources exposées à l’exécution. Un service d’approbation traite les exceptions à fort impact. Un système d’audit enregistre la décision et son résultat.

Ensemble, ces composants permettent aux règles de survivre au remplacement d’un modèle. Une équipe peut changer d’agent sans devoir reconstruire ses frontières les plus importantes dans le format de prompt d’un autre fournisseur.

Cette pérennité est au cœur de l’argument de Mozilla AI. Les modèles évolueront fréquemment. La propriété des dépôts, les obligations de conformité et les risques de production perdurent bien plus longtemps.

Le plan de contrôle devient le véritable mécanisme de sécurité

Une infrastructure d’agents fiable place des politiques applicables entre la requête d’un modèle et chaque action d’outil à fort impact.

Un plan de contrôle est la couche de confiance qui gère les accès, les politiques, le routage, les budgets et l’état opérationnel. Le modèle peut proposer une action, mais le plan de contrôle décide si et comment elle est exécutée.

Cette architecture commence par l’identité. Chaque exécution d’agent doit posséder une identité distincte de celle de l’opérateur humain et des autres processus automatisés. Des identifiants partagés compliquent l’attribution et rendent la révocation des autorisations imprécise.

L’exigence suivante est le principe du moindre privilège. Chaque tâche ne reçoit que les fichiers, commandes, services et destinations réseau dont elle a besoin. Les autorisations doivent expirer avec la tâche au lieu de rester disponibles pour les exécutions ultérieures.

Les recommandations de sécurité des sandbox d’OpenAI préconisent des charges de travail isolées, un trafic sortant restreint, des identifiants séparés et un accès négocié aux services tiers. Ces contrôles fonctionnent indépendamment de l’intention du modèle.

Les identifiants négociés sont particulièrement utiles. L’environnement d’exécution peut envoyer une requête approuvée sans voir un secret réutilisable. Un proxy de confiance fournit les identifiants uniquement pour la destination autorisée.

Cette conception réduit la valeur d’une divulgation accidentelle. Si du code généré affiche son environnement, des clés de production à longue durée de vie n’ont pas besoin d’apparaître. La révocation intervient également au niveau du courtier, plutôt qu’au sein de chaque espace de travail.

La médiation des outils offre un autre point d’application. L’infrastructure peut valider les arguments, rejeter les chemins dangereux, limiter le débit des requêtes et exiger une approbation pour certaines opérations.

Mozilla AI a exploré ce modèle au moyen des plugins de politique mcpd. Mozilla décrit l’authentification, la validation, la limitation de débit et la journalisation comme des fonctions pouvant se situer entre les agents et les serveurs d’outils.

Cet emplacement est important, car les serveurs Model Context Protocol peuvent exposer des actions sur des fichiers, des bases de données et des applications externes. Un intermédiaire central peut appliquer une politique cohérente sans faire confiance à chaque agent pour la reproduire.

Un plan de contrôle mature gère également l’état. Les workflows d’agents peuvent échouer après avoir exécuté certaines actions, mais avant d’avoir enregistré leur réussite. Relancer aveuglément l’ensemble de la tâche peut dupliquer des effets de bord externes.

L’infrastructure doit savoir quelles étapes sont terminées, lesquelles peuvent encore être relancées sans risque et lesquelles exigent une réconciliation. Un appel de création de pull request, une instruction de paiement ou un message à un client ne peut pas toujours être répété comme la lecture d’un fichier local.

L’approbation humaine doit intervenir à des frontières sélectionnées, et non après chaque étape. Des demandes d’approbation constantes annulent une grande partie de la valeur de la délégation. L’absence totale d’approbation laisse les décisions à fort impact entièrement dans la boucle du modèle.

Le juste milieu utile est une escalade fondée sur le risque. La lecture d’un dépôt peut se dérouler automatiquement. L’écriture dans une branche temporaire peut également être autorisée. La publication, le déploiement, la modification des autorisations ou la prise de contact avec des clients peuvent nécessiter une autorisation explicite.

Les politiques doivent examiner le contexte entourant l’action. Une commande peut être acceptable dans un environnement de test isolé, mais interdite en production. Une requête réseau peut être autorisée pour la documentation tout en étant bloquée vers des points de terminaison inconnus.

Les budgets nécessitent une application similaire. Un agent coordonnant plusieurs sous-agents peut générer des coûts plus rapidement qu’une personne surveillant un seul chat. Le plan de contrôle peut fixer des plafonds par tâche, équipe, fournisseur ou résultat.

Le plan de contrôle ouvert de Mozilla AI relie cet argument de gouvernance au routage des modèles. Otari est présenté comme une couche destinée au routage, aux budgets, aux contrôles d’accès, au déploiement et au basculement entre fournisseurs.

Le routage n’est pas seulement une optimisation des coûts. Différentes tâches peuvent exiger différentes frontières de confidentialité, cibles de latence ou capacités de modèle. L’infrastructure peut appliquer ces choix de manière cohérente au lieu de les intégrer partout dans le code applicatif.

Cette approche améliore également la portabilité. Une organisation peut remplacer un modèle sans abandonner sa logique de politique, ses traces historiques ou ses contrôles opérationnels. L’agent devient un composant d’un système détenu par l’organisation.

Pour les équipes d’ingénierie, cela peut préserver les connaissances institutionnelles. Une base de connaissances techniques consultable peut conserver les décisions d’architecture et la documentation locale. La politique d’exécution doit néanmoins toujours contrôler la manière dont les agents utilisent ces connaissances.

L’essentiel est la séparation. Les connaissances informent le modèle. La politique contraint ses actions. L’audit enregistre ce qui s’est passé. La reprise traite le travail incomplet.

Aucun composant isolé ne rend un agent fiable. Le plan de contrôle les coordonne afin qu’une erreur de jugement ne détermine pas l’ensemble du résultat.

Une infrastructure ouverte apporte du contrôle, pas une sécurité automatique

Posséder la pile d’agents améliore l’inspectabilité et la portabilité, mais le code ouvert n’élimine pas à lui seul le risque opérationnel.

Mozilla AI relie le contrôle de l’infrastructure à l’ouverture. Ce lien est compréhensible. Les organisations ne peuvent pas inspecter, modifier ou préserver pleinement un système de contrôle qui n’existe que derrière la frontière de service d’un fournisseur.

Une infrastructure ouverte peut réduire la dépendance. Les équipes peuvent conserver leurs politiques tout en changeant de fournisseur de modèles. Elles peuvent examiner le code d’application, ajouter des intégrations et déployer des composants sensibles dans des environnements qu’elles contrôlent.

Elle peut également maintenir la gouvernance au plus près de l’organisation qui porte le risque. Un hôpital, une banque, une administration publique ou une entreprise logicielle peut avoir besoin de règles d’approbation et de politiques de conservation différentes. Un paramètre par défaut hébergé ne peut pas représenter chaque obligation.

Toutefois, la propriété transfère la responsabilité. Un plan de contrôle auto-hébergé nécessite des mises à jour de sécurité, des revues d’accès, des sauvegardes, une supervision et une reprise testée. Un composant ouvert obsolète peut devenir une nouvelle faiblesse.

La transparence ne garantit pas une configuration correcte. Une équipe peut déployer un logiciel inspectable avec des paramètres par défaut permissifs, des identifiants partagés, une journalisation incomplète ou un accès réseau sans restriction. Le code source peut être ouvert alors que le déploiement reste dangereux.

Les journaux créent leurs propres compromis. Des traces riches facilitent les enquêtes, mais elles peuvent capturer du code propriétaire, des informations personnelles, des prompts et des résultats d’outils. Tout conserver indéfiniment peut entrer en conflit avec les objectifs de confidentialité et de minimisation.

Les équipes ont besoin de limites de conservation explicites. Elles doivent enregistrer suffisamment d’informations pour établir les responsabilités sans transformer le système d’audit en copie permanente de chaque entrée sensible.

La complexité des politiques constitue un autre risque. Un vaste ensemble de règles peut devenir difficile à comprendre. Des exceptions qui se chevauchent peuvent créer des lacunes, tandis que des contrôles trop stricts peuvent pousser les développeurs vers des outils non approuvés.

La réponse ne consiste pas simplement à ajouter davantage de politiques. Les équipes ont besoin de contrôles réduits et testables, liés à des risques précis. Chaque règle devrait avoir un responsable, une justification et une méthode de vérification.

Le comportement du modèle reste lui aussi pertinent. L’infrastructure peut bloquer les opérations interdites, mais elle ne peut pas garantir un code utile. Un agent peut respecter ses autorisations tout en produisant une implémentation incorrecte ou en omettant une exigence importante.

Les tests et la revue humaine restent donc partie intégrante du système. Des cas d’évaluation privés ou maintenus indépendamment peuvent aider à détecter les agents qui n’optimisent que pour les contrôles visibles. Les règles de propriété du code peuvent acheminer les modifications sensibles vers les réviseurs appropriés.

C’est la limite sceptique de la thèse de Mozilla AI sur l’infrastructure d’agents. Une meilleure infrastructure contient les défaillances, préserve les preuves et rend la reprise possible. Elle ne transforme pas un raisonnement incertain en ingénierie logicielle déterministe.

Les organisations devraient également résister à la tentation de considérer les journaux d’audit comme une preuve de sécurité. Un enregistrement détaillé peut montrer exactement comment un incident s’est produit. Prévenir l’incident exige des contrôles applicables et des politiques validées avant l’action.

Une question de gouvernance se pose également quant à savoir qui contrôle le plan de contrôle. Une politique centralisée peut protéger une organisation, mais elle peut aussi créer une autorité interne opaque. Les développeurs doivent comprendre pourquoi des actions ont été rejetées et comment fonctionnent les exceptions.

Une implémentation ouverte facilite cet examen, mais les processus comptent aussi. Les modifications de politique devraient faire l’objet d’une revue, de tests et d’un versionnage. Les dérogations d’urgence devraient expirer et rester visibles dans l’historique.

L’approche la plus solide considère l’ouverture comme un modèle de propriété plutôt que comme un label de sécurité. Les organisations gagnent la capacité d’inspecter et de modifier le système. Elles acceptent également la responsabilité de bien l’exploiter.

Ce compromis est plus crédible que la promesse d’une sécurité automatique. Il reconnaît qu’une délégation fiable découle de la discipline d’ingénierie, et non d’une seule fonctionnalité produit.

Trois signaux mettront à l’épreuve la thèse de Mozilla sur l’infrastructure

Le prochain test consistera à déterminer si les plateformes d’agents transforment les principes d’infrastructure en paramètres par défaut que les développeurs peuvent vérifier sans ralentir le travail ordinaire.

Le premier signal est la généralisation des autorisations limitées à la tâche. Il faudra observer si les agents de codage reçoivent un accès temporaire à des dépôts, répertoires, commandes et destinations réseau nommés. Une autorité étendue à l’ensemble de la machine affaiblirait concrètement l’argument de Mozilla AI, même si les fournisseurs promeuvent la sécurité ailleurs.

Le deuxième signal est la qualité des preuves. Les plateformes devraient exposer des enregistrements durables des appels d’outils, approbations, décisions de politique, modifications de fichiers et états de relance. Une transcription seule ne répondra pas à la question de savoir quelle autorité existait lorsqu’une action s’est produite.

Le troisième signal est la portabilité. Les équipes devraient pouvoir conserver leurs politiques, leurs traces et l’état de leurs workflows lorsqu’elles changent de modèle ou d’environnement de déploiement. Si la gouvernance reste liée à un seul fournisseur, le choix du modèle continue de contrôler le système environnant.

Ces signaux se renforcent mutuellement. Les autorisations limitées réduisent les dommages possibles. Les enregistrements d’audit révèlent si ces frontières ont fonctionné. La portabilité empêche ces frontières de disparaître lors de la prochaine migration de modèle.

Les développeurs devraient également surveiller les frictions dans le workflow quotidien. Une couche de contrôle qui interrompt constamment les actions à faible risque rencontrera de la résistance. Une couche qui masque les décisions de politique sera difficile à faire confiance et à déboguer.

Les systèmes efficaces rendront les opérations sûres habituelles et les opérations exceptionnelles explicites. Ils permettront aux agents de lire, raisonner, tester et préparer des modifications dans des environnements délimités. Ils s’arrêteront avant les actions ayant des conséquences externes ou irréversibles.

L’argument de Mozilla AI en faveur de l’infrastructure d’agents sera renforcé lorsque ces fonctionnalités deviendront des attentes standard pour les produits. Il sera affaibli si les agents continuent d’acquérir de l’autorité alors que les contrôles restent des tableaux de bord facultatifs ou des modèles de prompt.

Pour les équipes qui adoptent aujourd’hui des agents de codage, la question immédiate n’est pas de savoir si le modèle le plus récent obtient un meilleur score. Demandez-vous à quoi l’agent peut accéder, quelles actions exigent une approbation et si chaque décision peut être reconstituée ultérieurement. Demandez-vous ensuite si ces protections appartiennent à votre organisation ou disparaissent avec le fournisseur. Une meilleure IA restera utile, mais l’infrastructure détermine si cette intelligence peut être déléguée de manière responsable.