Agents IA : le vrai risque est organisationnel, pas technique

Deux articles ont récemment circulé dans la communauté tech, et ils défendent des positions qu’on pourrait croire opposées.

Le premier (Context Management and MCP), signé par le créateur du serveur MCP de Sentry, explique que la valeur des outils d’IA réside dans leur capacité à guider l’agent : des descriptions riches, du contexte structuré, des réponses formatées pour orienter les décisions du modèle. Bref, il faut construire pour l’agent.

Le second prend le contrepied exact : arrêtez d’optimiser pour les agents, construisez pour que les humains puissent rester aux commandes. Le vrai blocage, c’est la vitesse à laquelle quelqu’un dans votre organisation peut comprendre ce qu’un système automatisé a fait, et en répondre.

Ces deux visions semblent incompatibles. Elles pointent pourtant vers le même angle mort, et c’est un angle mort de direction, pas de code.

Optimiser pour les agents IA ou pour l’humain ?

L’argument en faveur de l’optimisation pour l’agent est séduisant. Plus vous donnez de contexte structuré à un LLM, mieux il agit. C’est ce que David Cramer appelle le « steering » : fournir à l’agent des descriptions d’outils suffisamment précises pour qu’il choisisse le bon outil, l’utilise correctement, et interprète la réponse de façon utile. L’idée a du mérite. Quand c’est bien fait, un agent peut résoudre un bug en production en une seule passe.

Mais cette approche suppose quelque chose de fondamental : que quelqu’un dans l’organisation comprend ce que l’agent vient de faire, pourquoi il l’a fait, et peut décider si c’était la bonne chose. C’est là que le second article intervient, avec une question que peu de dirigeants se posent : quand votre agent corrige un bug, déploie du code ou modifie une configuration, combien de temps faut-il à quelqu’un pour comprendre ce qui s’est passé ?

Si la réponse est « personne ne sait » ou « on verra bien », vous avez un problème de gouvernance tech, pas un problème d’IA.

Le « Time to Accountability » : un concept que les dirigeants devraient connaître

L’article sur l’accountability introduit un concept simple mais puissant : le Time to Accountability. Combien de temps faut-il pour qu’un humain puisse observer le comportement du système, reproduire un problème, et expliquer ce qui se passe ? C’est ça, le vrai indicateur de maturité d’une organisation face à l’intelligence artificielle.

On connaît cette situation : les LLM permettent de produire du code 10, 50, parfois 100 fois plus vite. Mais la capacité d’un humain à comprendre ce code, à en vérifier la pertinence, à en assumer les conséquences en production, elle n’a pas bougé. L’écart entre la vitesse de production et la vitesse de compréhension se creuse chaque mois.

Pour un dirigeant, cette asymétrie devrait être une préoccupation majeure. Un agent IA qui corrige un problème en 30 secondes, c’est impressionnant. Un agent qui crée un problème que personne ne comprend pendant 3 jours, c’est coûteux. Et entre les deux, la différence ne tient pas à la qualité de l’agent. Elle tient à la capacité de votre équipe à superviser ce qu’il produit.

Vos systèmes « marchent par accident », et l’IA va le révéler

Il y a un constat que nous faisons régulièrement en audit : la plupart des organisations tech fonctionnent grâce à la connaissance tacite de quelques personnes clés. Le système compile, les transactions passent, les déploiements se font. Mais quand on gratte un peu, personne ne sait vraiment expliquer pourquoi ça marche dans cet ordre-là, pourquoi ce service redémarre de cette façon, pourquoi cette dépendance est à cette version.

L’un des articles le formule ainsi : tout « happens to work ». Ça fonctionne par habitude, par hasard, par accumulation de décisions que personne n’a documentées. À petite échelle, c’est gérable. On relève les exceptions, on redemande à l’ingénieur qui était là il y a 4 ans, on prie pour que les cas limites ne reviennent pas.

Mais les agents IA changent l’échelle. Quand un agent peut lancer 50 modifications en une journée, quand il interagit avec des systèmes que même vos développeurs ne maîtrisent que partiellement, les fondations fragiles cèdent. Ce qui « marchait par accident » cesse de marcher. Et personne ne sait pourquoi, parce que personne ne comprenait vraiment pourquoi ça marchait au départ.

Nous voyons ce phénomène se répéter chez nos clients. L’IA ne crée pas les dysfonctionnements. Elle accélère la mise en lumière de dysfonctionnements qui existaient déjà, mais que la faible cadence de développement rendait tolérables.

Ce que les agents IA vont concrètement changer pour un dirigeant

Avant de décider si vous adoptez tel ou tel agent, avant de choisir entre MCP et CLI (un débat qui passionne les équipes tech mais qui est largement hors sujet pour un comité de direction), posez-vous des questions plus fondamentales.

Est-ce que vos systèmes sont suffisamment observables pour qu’on puisse comprendre ce qu’un agent y a fait ? Est-ce que votre équipe est en capacité de diagnostiquer un problème causé par une action automatisée, dans un délai acceptable ? Et surtout : quand l’automatisation produit un résultat inattendu, qui dans votre organisation en répond ?

Ces questions ne sont pas techniques. Elles relèvent de la gouvernance tech, de l’organisation, de la clarté des responsabilités. Et dans notre expérience, les organisations qui peinent à y répondre sont souvent celles où la tech fonctionne déjà en boîte noire, bien avant l’arrivée de l’IA.

Le vrai prérequis à l’adoption des agents, ce n’est pas une stack technique particulière. C’est une organisation où quelqu’un peut dire : « Je sais ce que le système a fait, je comprends pourquoi, et je suis en mesure de corriger si nécessaire. » La majorité des entreprises tech que nous accompagnons n’en sont pas là aujourd’hui, et beaucoup n’en avaient pas conscience avant qu’on pose la question.

La tension qui va structurer les prochaines années

Optimiser les outils pour les agents et garder l’humain aux commandes, ces deux objectifs vont coexister, et souvent se contrarier. Plus vous donnez d’autonomie à un agent, plus la question de la supervision devient critique. Plus vous multipliez les agents, plus la chaîne de responsabilité se complexifie.

Les organisations qui s’en sortiront ne seront pas forcément celles qui auront adopté l’IA le plus vite. Ce seront celles qui auront posé la question de la responsabilité avant celle de l’adoption. Et qui auront osé regarder l’état réel de leurs fondations avant d’y empiler une couche supplémentaire.

C’est un chantier moins spectaculaire qu’une démo d’agent IA. Mais c’est probablement celui qui déterminera si l’IA devient un levier ou un risque supplémentaire dans votre organisation.

Vous vous demandez où en est votre organisation sur ces sujets ? Nos audits tech commencent souvent par là : comprendre qui maîtrise quoi, ce qui fonctionne par habitude plutôt que par design, et où se situent les vrais risques avant d’accélérer.