Photo by Frans van Heerden : https://www.pexels.com/photo/scenic-photo-of-water-dam-during-daytime-2699258/
Il y a une question qui me tourne dans la tête depuis des semaines, une de ces questions qui vous tombent à 23 h, quand vous repensez à tout ce qui a été produit dans la journée. La question est simple, presque banale dans sa formulation : comment gouverner ce qu’on n’arrive plus à lire ?
Je ne parle pas dans l’abstrait. Je parle de ce qui se passe chaque jour dans les organisations qui utilisent des agents IA. De pull requests qui contiennent des modifications générées automatiquement, de specs co-écrites avec Claude, de configurations suggérées par des systèmes qui comprennent l’infrastructure mieux que celles et ceux qui doivent les valider. De cette sensation subtile, presque imperceptible, d’approuver des choses qu’on ne comprend qu’en partie.
Le fait qu’il n’existe pas de réponse propre à cette question est déjà significatif. Et le fait que cette même question revienne de plus en plus souvent, dans les conseils d’administration, les directions juridiques, les équipes compliance, suggère que nous traversons un point de non-retour. Pas une évolution graduelle. Un point de non-retour.
Le présupposé qui s’effondre
La gouvernance traditionnelle repose sur un présupposé si ancré qu’il en est devenu invisible : qu’il y ait assez de temps pour comprendre ce qui a été produit avant que cela ne soit mis en production. Code review. Audit de documents. Validation de contrats. Vérification d’analyses. Signature des deliverables. Tout cela a fonctionné des décennies durant parce que le goulot d’étranglement était la production. Le temps nécessaire à créer quelque chose était assez long pour que le processus de validation suive.
Mais quand un système IA génère en minutes ce qui demandait des semaines, ce présupposé s’effondre. Il ne plie pas, ne s’adapte pas : il s’effondre. Et cela ne concerne pas que le code. Cela concerne tout.
Où cela s’effondre, en pratique
Je pense aux documents contractuels. Un agent IA peut aujourd’hui rédiger des projets de contrats, des clauses spécifiques, des réponses à contestations, des avis préliminaires. La qualité est souvent assez plausible pour passer une lecture rapide. Mais « assez plausible » en juridique peut signifier des clauses qui semblent protectrices et ne le sont pas, des références normatives obsolètes présentées avec assurance, des omissions qui n’apparaissent qu’en cas de contentieux. Le risque n’est pas l’erreur grossière. C’est la subtilité de l’erreur dans un contexte où la subtilité est tout.
Je pense aux analyses financières. Dashboards, projections, analyses de scénario, business cases. Un CFO qui reçoit une analyse générée ou co-générée par IA approuve-t-il quelque chose qu’il comprend ? Ou valide-t-il la plausibilité superficielle de chiffres qui suivent une logique que personne n’a réellement vérifiée ? Le problème n’est pas si les chiffres sont bons. Le problème est si les hypothèses sous-jacentes sont correctes, si les modèles appliqués sont appropriés, si les sources de données sont fiables. Toutes choses qui demandent une compétence métier pour être évaluées, compétence que le processus de review présuppose mais que la vitesse de production rend de plus en plus difficile à appliquer.
Je pense aux communications externes. Mails clients, réponses à appels d’offres, documentation produit, manuels, policies internes. Chaque organisation produit quotidiennement des milliers d’artefacts textuels. Quand une part significative est générée ou assistée par IA, qui garantit la cohérence avec le positionnement de l’entreprise ? Qui vérifie qu’une réponse à un client ne crée pas des attentes que l’organisation ne pourra pas satisfaire ?
Et puis il y a la compliance. Là, le paradoxe est maximal. Nous sommes en pleine vague réglementaire européenne : AI Act, Cyber Resilience Act, Product Liability Directive, EAA, RGPD qui continue d’évoluer. Les organisations doivent produire de la documentation de compliance, des évaluations de risque, des registres, des policies. La tentation d’utiliser l’IA pour accélérer cette production est très forte. Mais on parle de documents qui attestent la conformité à des normes qui, dans certains cas, concernent justement l’usage de l’IA. Il y a quelque chose de circulaire et perturbant à utiliser un système IA pour déclarer que ses propres systèmes IA sont conformes aux règles sur l’IA.
Un problème épistémologique organisationnel
Le problème n’est pas seulement la vitesse. C’est le volume combiné à l’opacité. Une équipe qui utilise l’IA pour générer code, configurations, documents, analyses, communications, décisions architecturales produit une quantité d’artefacts qu’aucun processus de review humaine ne peut réalistement couvrir à 100 %. Sans doute pas non plus à 50. Sans doute pas non plus à 20, si l’on est honnête avec soi-même.
Mais le pire problème est ailleurs : beaucoup de ces artefacts sont assez plausibles pour passer un contrôle superficiel. Ce qui est presque pire que s’ils étaient manifestement faux. Une erreur évidente est interceptée. Une erreur plausible est approuvée, déployée, publiée, signée, et découverte seulement quand elle produit des conséquences.
Je me rends compte que nous affrontons ce qu’on pourrait appeler un problème épistémologique organisationnel : l’organisation en sait moins sur ce qu’elle produit. Et l’écart se creuse chaque jour.
Trois directions, aucune définitive
Je n’ai pas de solutions définitives. Personne n’en a, et qui dit en avoir sous-estime probablement le problème. Mais quelques directions semblent sensées, même si aucune n’est résolutive.
La première, c’est ce qu’on pourrait appeler le passage du contrôle ponctuel au contrôle structurel. Si tu ne peux pas contrôler chaque output, tu dois contrôler le système qui produit les outputs. Cela veut dire investir bien plus dans la définition de contraintes en amont, des spécifications rigoureuses, des guardrails automatisés, du policy as code, plutôt que dans la review en aval. C’est le sens du spec-driven development : si la spécification est solide, le range d’erreur de l’output se réduit. Il ne disparaît pas, mais il est contenu.
Pour les documents juridiques : des templates vérifiés avec des placeholders clairs, pas de génération libre. Pour les analyses financières : des modèles validés avec inputs contrôlés, pas de feuilles blanches. Pour les configurations : des baselines certifiées avec variations explicites et justifiées. Le principe sous-jacent est simple : déplacer l’intelligence — et donc la responsabilité — vers la définition du problème, pas vers la génération de la solution.
La deuxième direction concerne ce qu’on vérifie. Tu ne peux pas lire tout le code généré. Tu ne peux pas relire chaque document. Tu ne peux pas recontrôler chaque analyse. Mais tu peux définir des invariants à respecter et les tester automatiquement. Pour le code : tests automatisés, type checking, analyse statique, vérifications de sécurité. Pour les documents : checklists automatisées, validation de structure, contrôles de cohérence terminologique. Pour les configurations : policies de compliance as code, drift detection, validation pré-déploiement.
C’est un changement de paradigme : on passe de « j’ai lu et approuvé cet artefact » à « cet artefact respecte ces propriétés vérifiables ». C’est ce qu’on fait déjà avec les tests automatisés en software. Sauf que cela devient l’unique ligne de défense réaliste pour tout.
La limite est évidente : les propriétés vérifiables sont un sous-ensemble des propriétés désirables. Tu peux vérifier qu’un contrat contient certaines clauses, pas qu’il est stratégiquement approprié. Tu peux vérifier qu’une analyse est cohérente en interne, pas que les hypothèses sont correctes. Mais c’est quand même bien mieux que rien.
La troisième direction est peut-être la plus inconfortable : de l’IA qui contrôle de l’IA. Reviewers automatiques. Validateurs spécialisés. Systèmes qui vérifient l’output d’autres systèmes. Le problème récursif est évident : qui contrôle les contrôleurs ? Si je n’ai pas confiance dans l’output de l’IA qui produit, pourquoi devrais-je avoir confiance dans l’output de l’IA qui vérifie ?
Mais c’est probablement inévitable. Et la question devient : comment garder des points d’intervention humaine aux moments qui comptent vraiment ?
Mon hypothèse, encore à valider sur le terrain, c’est que le rôle humain se déplacera vers les décisions architecturales, les choix éthiques, la gestion des exceptions, la calibration des systèmes de contrôle. Un autre rôle. Moins opérationnel, plus stratégique. Moins faire et plus décider les règles du faire.
Le risque organisationnel
Qu’est-ce qui m’inquiète le plus dans tout cela ? Pas tant le risque technique. Les bugs se trouvent. Les erreurs dans les documents émergent. Les configurations fausses se manifestent. Ce qui m’inquiète, c’est le risque organisationnel : des équipes qui s’habituent à faire confiance aux outputs sans les comprendre, qui perdent peu à peu la capacité d’évaluer ce qu’elles approuvent.
Je le vois déjà. Des développeurs qui acceptent du code généré sans le lire. Des managers qui valident des analyses sans vérifier les hypothèses. Des responsables compliance qui signent des documents qu’ils ont seulement parcourus. Compréhensible, on est tous sous pression, tous avec plus à faire qu’on ne peut gérer. Mais aussi dangereux.
La gouvernance la plus importante n’est peut-être pas celle qui porte sur les systèmes, mais celle qui porte sur les compétences des personnes censées les gouverner. Si nous perdons la capacité de comprendre ce que nous produisons, nous perdons la capacité de le gouverner. Indépendamment du nombre de couches de contrôle automatique qu’on intercale.
Qui répond, et comment naviguer l’incertitude
Il y a aussi une question qui, en Italie et en Europe avec l’AI Act, devient particulièrement pressante : qui est responsable ? Quand un contrat généré par IA contient une erreur qui cause un dommage, qui répond ? L’opérateur qui l’a utilisé ? Le fournisseur du système IA ? Le manager qui a approuvé ? L’organisation dans son ensemble ? Quand une configuration suggérée par IA crée une vulnérabilité, la chaîne de responsabilité devient soudain très importante.
Le cadre normatif européen tente de répondre. L’AI Act définit des obligations pour fournisseurs et deployers. La PLD étend la responsabilité pour produits défectueux. Le CRA introduit des exigences de sécurité by design. Mais la vérité, c’est que la norme court derrière la technologie, et entre-temps les organisations doivent prendre des décisions. Des décisions qui auront des conséquences juridiques fondées sur des règles encore pas tout à fait claires.
Ce qu’on peut faire, c’est construire de la traceability. Savoir quels artefacts ont été générés ou influencés par l’IA, avec quels prompts, dans quelles conditions. Cela ne résout pas le problème de la responsabilité, mais cela permet au moins de reconstruire ce qui s’est passé.
J’écris tout cela et je me rends compte combien le terrain est incertain pour tout le monde. Il y a des principes opérationnels qui semblent sensés : présomption de contrôle structurel, invariants explicites, traçabilité obligatoire, intervention humaine stratégique, compétence comme prérequis, acceptation de l’incertitude. Mais des principes en construction, imparfaits, en évolution, probablement destinés à être dépassés rapidement par la vitesse du changement.
Et il y a quelque chose de profondément frustrant dans cette situation. Pendant des années, qui travaille dans ce champ avait pour mission de trouver des solutions, de donner des réponses, d’avoir un plan clair. Maintenant on se retrouve à naviguer un territoire où les questions sont plus claires que les réponses, où chaque solution ouvre de nouveaux problèmes, où la chose la plus honnête à dire est « je ne sais pas, mais j’essaie de comprendre ».
C’est peut-être le nouveau rôle de qui gouverne des systèmes complexes : ne pas avoir toutes les réponses, mais poser les bonnes questions et bâtir des structures qui permettent de s’adapter quand les réponses changent. C’est moins rassurant qu’un framework défini avec cinq best practices et trois piliers stratégiques. Mais c’est la seule gouvernance honnête possible quand le monde produit plus vite que nous ne pouvons comprendre.
Je me demande souvent où d’autres, au milieu de cette transformation, sentent le plus la tension. Sur la vitesse de production, sur la capacité d’évaluation, ou sur autre chose que je ne vois pas encore. Parce que ce qui m’inquiète peut-être le plus, c’est cela : ne pas savoir ce que je ne vois pas.
Ce qu'il faut retenir
La review humaine de tout est un présupposé tacite qui, avec les agents IA, s’effondre tout simplement.
Trois mouvements opérationnels : gouvernance par échantillonnage statistiquement significatif, policy-as-code pour des classes entières d’erreurs, observabilité agressive en production.
Le risque le plus sérieux n’est pas l’erreur grossière — c’est l’erreur plausible qui passe une review superficielle.
PLD et AI Act mettent la responsabilité sur le producteur et le deployer : sans rôles assignés, vous ne gouvernez pas, vous espérez.
Questions & réponses
Comment gouverner ce qu'on n'arrive plus à lire ?
C’est la question centrale de la gouvernance IA en 2026. Pull requests générées automatiquement, documents co-écrits avec Claude, configurations suggérées par des systèmes qui comprennent l’infrastructure mieux que celles et ceux qui doivent l’approuver. La gouvernance traditionnelle suppose du temps pour comprendre ce qui a été produit avant la mise en production — et ce présupposé a sauté. Il ne plie pas, il s’effondre.
Pourquoi la gouvernance ne s'adapte-t-elle pas simplement au rythme de l'IA ?
Parce qu’elle repose sur un goulot humain : la lecture. Code review, audit de documents, validation de contrats — tout demande un cerveau qui lit ligne par ligne. Quand un agent IA génère en minutes ce qui exigeait des semaines, ce n’est pas que la review « doit accélérer » : elle doit être repensée. Tout lire n’est plus une option.
Quelle est la réponse pratique pour CTO et responsables juridiques ?
Trois mouvements : (1) gouvernance par sampling intelligent — vérifier un pourcentage statistiquement significatif au lieu de tout ; (2) contraintes automatiques en amont (policy-as-code, type systems, property tests) qui attrapent des classes entières d’erreurs sans lecture humaine ; (3) observabilité agressive en production, parce que ce qu’on n’a pas vérifié avant, on doit pouvoir le corriger après. L’inspection totale ex-ante cède le pas à la vérification distribuée dans le temps.
Qui est responsable si un agent IA se trompe ?
La réponse juridique en chemin (PLD, AI Act) : le producteur ou deployer. Mais la responsabilité opérationnelle doit être conçue, pas découverte après coup : qui a écrit le prompt, qui a approuvé le déploiement, qui surveille l’output en production, qui peut intervenir si une erreur émerge. Une organisation qui n’a pas explicitement attribué ces rôles ne gouverne pas — elle espère.
L'auteur
