La demande arrive presque toujours par le même chemin. Une équipe a essayé un agent de code pendant quelques semaines, les résultats sont bons, l'enthousiasme est réel, et quelqu'un finit par remonter le sujet à la direction des systèmes d'information. À ce moment-là, l'arbitrage ne porte plus sur l'outil : il porte sur le risque, et le document qui permettrait de trancher n'existe nulle part.
Avant d'autoriser un agent de code dans une organisation, cinq points se vérifient : où part le code, ce que l'agent a le droit de faire, comment ses actions sont tracées et réversibles, quels secrets il peut lire, et ce qui se passe le jour où le service est indisponible. Aucun de ces points ne se règle après coup, parce que chacun engage soit une décision d'architecture, soit une négociation contractuelle que personne ne rouvrira une fois les équipes installées dans leurs habitudes.
Où part votre code, et qui peut le lire
C'est la première question posée dans toutes les réunions auxquelles j'assiste, et elle est légitime : la très grande majorité des outils agentiques fonctionnent en appelant une interface hébergée par leur éditeur. Votre code source, vos noms de tables, vos règles métier, les commentaires un peu trop honnêtes laissés par un développeur en 2019 : tout cela quitte votre système d'information le temps d'un appel. Pour beaucoup d'organisations ce n'est pas un problème, parce que leur code n'est pas l'actif sensible. Pour d'autres c'est rédhibitoire, et il vaut mieux le découvrir avant que trois équipes aient bâti leur quotidien autour de l'outil. Si le code ne peut pas sortir, deux voies existent, et elles ne se valent pas.
Héberger des modèles ouverts en interne
Aucun octet ne quitte votre réseau, et c'est parfois la seule option acceptable (défense, santé, certains contrats clients). En contrepartie, un écart de qualité net avec les meilleurs modèles propriétaires sur les tâches longues, du matériel à financer et une compétence d'exploitation à construire. Le choix tient quand la contrainte est non négociable, pas quand on cherche à économiser.
Passer par une plateforme cloud déjà contractualisée
Vous consommez les modèles des éditeurs à travers l'infrastructure d'un fournisseur avec lequel votre organisation a déjà un cadre juridique, une localisation de données définie et un interlocuteur. La qualité reste celle des meilleurs modèles, et le travail à faire est contractuel plutôt que technique : vérifier que la clause couvre l'usage agentique, pas seulement l'hébergement.
Sur ce terrain, je me garde d'affirmer quoi que ce soit de précis au sujet d'un éditeur nommé. Les politiques de rétention, les engagements de non-entraînement et les certifications évoluent plusieurs fois par an, et une affirmation lue dans un article de blog ne protégera personne lors d'un audit. Ce qui se transmet, en revanche, ce sont les questions. Combien de temps les requêtes sont-elles conservées, et sous quelle forme ? Le contenu soumis sert-il à entraîner des modèles, et par quel mécanisme contractuel est-ce exclu ? Dans quelle juridiction les données transitent-elles ? Une bonne réponse est datée, écrite, opposable, et elle renvoie à une clause plutôt qu'à une page marketing.
Le vrai sujet n'est pas le modèle, c'est ce que l'agent a le droit de faire
Voilà le point que je vois sous-traité presque partout, alors que c'est celui qui produira l'incident. Un agent moderne ne se contente pas de proposer du texte : il exécute des commandes, écrit des fichiers, lance des tests, appelle des services, parfois interroge une base ou déclenche un déploiement. Chaque outil que vous lui ouvrez est une porte, et une porte s'évalue en se demandant ce que la pire action possible derrière elle coûterait. Un agent qui peut lire le dépôt et proposer des modifications présente un risque faible. Le même agent avec un accès en écriture à une base de production, ou le droit d'appeler une interface interne non authentifiée, change complètement de catégorie, indépendamment de la qualité du modèle qui le pilote.
La bonne pratique tient en une phrase : le périmètre doit être fermé et explicite, c'est-à-dire que tout est interdit sauf ce qui est listé. L'inverse, interdire quelques commandes dangereuses et laisser passer le reste, ne tient pas, parce que vous ne pouvez pas énumérer à l'avance tout ce qu'un système capable de raisonner saura inventer. Et cet enclos doit être technique, pas déclaratif : un périmètre écrit dans les instructions données à l'agent est une consigne, pas une barrière. J'ai décrit ce principe à propos d'une astreinte d'exploitation tenue par un agent autonome, où les droits sont bornés au niveau de l'infrastructure, précisément parce que la consigne se contourne et pas le contrôle d'accès.
La traçabilité se gagne en passant par le canal normal du projet
Un responsable sécurité veut pouvoir répondre à trois questions après coup : qui a modifié quoi, par quel chemin, et peut-on revenir en arrière. La bonne nouvelle, c'est que vous n'avez presque rien à inventer : vos projets possèdent déjà ce mécanisme sous la forme du gestionnaire de versions, de la revue par les pairs et de l'historique de déploiement. Un agent qui produit ses modifications sous forme de propositions soumises à relecture, signées, horodatées, rattachées à une demande identifiée, s'inscrit dans un dispositif que vos équipes savent déjà auditer. Vous n'avez pas un nouveau risque à gérer : vous avez un contributeur de plus dans un circuit qui existe.
Un agent qui agit à l'intérieur du canal de modification normal du projet pose infiniment moins de problèmes qu'un agent qui agit à côté.
C'est aussi le critère qui disqualifie le plus vite certaines configurations. Un agent qui applique directement ses changements sur un environnement, sans trace exploitable ni point de retour, vous prive de la seule chose qui compte quand quelque chose se passe mal : la capacité de reconstruire la séquence des événements. Je pose donc toujours la même question en atelier de cadrage, et elle fait plus de bruit que celle de l'hébergement. Si cet agent se trompe un mardi à seize heures, combien de temps faut-il pour s'en apercevoir, et combien pour revenir en arrière ? Quand la réponse est « quelques minutes, par le mécanisme habituel », la suite de la discussion devient nettement plus simple.
Un agent lit votre dépôt, donc il lit vos secrets
Ce point mérite d'être traité seul, parce qu'il transforme une négligence ancienne en exposition immédiate. Beaucoup de dépôts contiennent encore, quelque part, une clé en clair dans un fichier de configuration, un mot de passe de base dans un script d'amorçage, un jeton dans un ancien fichier d'exemple que personne n'a nettoyé. Jusqu'ici, ces secrets étaient accessibles à toute personne ayant accès au dépôt, ce qui était déjà un problème, mais un problème lent. Un agent, lui, lit le dépôt en entier, systématiquement, et peut transmettre ce qu'il lit à l'extérieur. La vulnérabilité ne change pas de nature, elle change de vitesse.
Chercher les secrets en clair dans un dépôt et son historique est un travail court et outillé, qu'on sait faire depuis longtemps. Lancez-le avant d'ouvrir l'accès. Et vérifiez au passage que les identifiants de l'agent lui-même sont distincts de ceux des humains : c'est ce qui permet de lui couper l'accès sans couper celui de toute une équipe.
Ce que vous devenez le jour où le service est indisponible
La dernière question est rarement posée, et c'est dommage, parce qu'elle est la plus structurante à deux ans. Une équipe qui a construit sa vitesse sur un service externe se retrouve un jour devant une panne de plusieurs heures chez son fournisseur, et la vraie mesure n'est alors pas le temps d'indisponibilité : c'est ce que l'équipe sait encore faire sans l'outil. La parade n'est pas de s'en priver, elle est d'exiger que le travail reste lisible sans lui : les décisions d'architecture et leurs raisons écrites dans le dépôt, les modifications passées par une relecture humaine qui engage quelqu'un, et aucun composant critique devenu une boîte noire que seul un agent sait relire. Cette discipline rend d'ailleurs les agents meilleurs, parce qu'un projet qui sait expliquer ses contraintes obtient davantage de n'importe quel modèle, comme je le développe dans le guide de l'IA agentique.
Ce que j'en retiens après plusieurs cadrages
Les organisations qui bloquent le plus longtemps ne sont pas celles qui ont les contraintes les plus fortes : ce sont celles qui traitent le sujet comme une question d'outil, donc comme une question qui se tranche par un oui ou par un non. Les cinq points ci-dessus ne produisent pas une autorisation, ils produisent un périmètre, et un périmètre se négocie. On commence souvent par un dépôt non critique, des droits en lecture, des propositions soumises à revue, et on élargit selon ce qu'on observe. Fait sérieusement, ce cadrage sert bien au-delà de l'outil du moment : c'est le travail que je mène en accompagnement au déploiement de l'IA agentique, et quand il s'agit surtout de mettre tout le monde au même niveau sur le risque, une formation de deux ou trois jours débloque la décision plus vite qu'un comité de plus.
Et maintenant ?
Où en êtes-vous ?
Choisissez la situation qui vous ressemble. Pour chacune : ce que je vous conseille de lire, et ce que je peux faire avec vous.
Je veux mettre mes équipes à l'IA agentique
Par où commencer, dans quel ordre, et avec quels garde-fous.
Mes développeurs utilisent l'IA, sans que rien ne change vraiment
Un gain réel, mais très en dessous de ce que la méthode permet.
Mon entreprise doit se digitaliser, sans savoir par quel bout
Commencer par ce qui rapporte, pas par l'outil le plus visible.
ou appelez-moi au 06 20 52 03 69