Ancrée ou améliorante ? La question que votre audit de l'IA ne pose pas

La plupart des discussions sur la gouvernance de l’IA abordent l’adoption par l’ingénierie comme une décision en attente. Ce n’est pas le cas. Les équipes d’ingénierie utilisent déjà des assistants de codage par IA tous les jours, dans l’IDE, sur les dépôts de production, lors de la révision du code. La question de la gouvernance aurait dû se poser il y a des mois.

Ce calendrier change la question qui mérite d’être posée. Non pas « devons-nous l’adopter ». Cela a été décidé équipe par équipe, généralement sans approbation formelle. La question utile est plus restreinte et plus difficile. Cette adoption a-t-elle rendu l’organisation plus performante, ou a-t-elle simplement rendu l’ancien processus plus agréable à exécuter ?

L’illusion de tout remplacer

Le 1er réflexe, lorsqu’on remarque une adoption non gouvernée, est de la traiter comme un défaut. Retirer l’outil. Restaurer l’ancien processus. Reprendre la gouvernance à 0. Ce réflexe est mauvais, et pas seulement parce que l’équipe qui a créé des habitudes autour de l’outil le détestera.

Vous ne pouvez pas annuler l’adoption. Les flux de travail se sont déjà remodelés en supposant que l’aide de l’IA est là : cycles de révision, estimation, intégration, habitudes de documentation. Retirer l’outil ne restaure pas le processus que vous aviez avant. Cela vous en donne un pire. L’ancien flux de travail, sans la mémoire musculaire que les gens en avaient, plus un vide là où se trouvaient les habitudes liées à l’IA. À ce stade, la gouvernance n’est pas là pour inverser l’adoption. Elle est là pour façonner l’adoption qui a déjà eu lieu.

Le piège de la satisfaction face à la vitesse

Voici la conclusion qui devrait inquiéter tout responsable technique considérant le sentiment des développeurs comme la preuve que l’IA fonctionne. Une étude contrôlée rigoureuse de 2026 a révélé que les développeurs étaient 19 % plus lents sur les tâches lorsqu’ils utilisaient l’assistance de l’IA. Ils pensaient être environ 20 % plus rapides. Ce n’est pas une erreur d’arrondi. C’est un écart de perception suffisant pour inverser le signe du résultat.

C’est là le piège. Une IA qui donne le sentiment d’être productif n’est pas la même chose qu’une IA qui rend l’organisation plus performante, et les 2 sont plus faciles à confondre que ne l’admettent la plupart des audits. Le rapport Global AI at Work 2026 du BCG a interrogé près de 12 000 employés de 1ère ligne. 42 % ont déclaré gagner l’équivalent d’1 journée de travail complète chaque semaine avec l’IA. 66 % ont déclaré n’avoir reçu que peu ou pas de directives sur ce qu’ils devaient faire de ce temps, et 50 % ne le réorientaient vers rien de plus stratégique. Le temps est gagné. L’organisation ne devient pas plus performante en retour, car personne n’a rien construit pour capter ce gain.

C’est encore pire. Des chercheurs de Stanford et de BetterUp ont nommé un mode de défaillance qui en découle : le « workslop », un résultat généré par l’IA qui semble abouti mais ne tient pas à l’usage. 40 % des travailleurs américains ont déclaré avoir reçu du workslop d’un collègue au cours du mois dernier, et chaque cas a coûté environ 2 à 3,5 heures de retouche en aval. Ce travail de retouche n’apparaît jamais dans les métriques d’adoption. Il apparaît plus tard et discrètement, dans les cycles de révision et de réécriture, ce qui est exactement l’endroit où la plupart des audits de l’IA ne regardent pas.

Plus rapide n’est pas mieux. Plus facile n’est pas mieux. Mieux, c’est mieux.

Rien de tout cela n’est un argument contre l’ingénierie assistée par l’IA. C’est un argument contre la mesure des mauvais indicateurs. La vitesse et la simplicité sont des moyens. Ce ne sont pas les résultats. Traitez-les comme le résultat et vous obtenez une équipe qui se sent plus rapide tout en livrant le même taux de défauts, ou qui se sent plus productive tout en générant plus de retouches qu’elle n’en évite.

La question indispensable à tout audit de l’IA, et qui n’est généralement pas posée : cela améliore-t-il le processus, ou cela automatise-t-il la version que nous avions déjà ? Un pipeline de révision qui exécute des contrôles assistés par l’IA et détecte toujours les mêmes catégories de bugs qu’auparavant n’est pas amélioré. C’est le même pipeline avec un 1er passage plus rapide, et l’hypothèse non testée qu’un 1er passage plus rapide signifie un meilleur résultat.

Ce qu’examine un audit honnête

L’utilisation ancrée de l’IA demande : sommes-nous plus rapides dans ce que nous faisions déjà ? L’utilisation améliorante de l’IA demande : pouvons-nous maintenant faire quelque chose que nous ne pouvions pas faire avant, ou détecter quelque chose qui nous échappait ? La 1ère question est confortable, et un tableau de bord d’utilisation y répond. La 2e implique d’examiner les résultats. Taux de défauts. Heures de retouche. Décisions modifiées car une capacité existe qui n’existait pas l’année dernière. Ni le sentiment, ni la vitesse.

La plupart des audits s’arrêtent à la 1ère question car l’outillage y répond déjà. Les organisations qui tirent une réelle valeur de l’IA sont celles prêtes à se pencher sur la 2e.

Sources : Fortune, “Why AI is raising worker productivity but not making the economy more efficient”, 27 mai 2026 ; Fortune, “AI productivity gains are real but so is bad management”, 5 juin 2026 (rapport Global AI at Work 2026 du BCG) ; Dr Philippa Hardman, “The Illusion of AI Productivity Gains”, avril 2026 (Hancock et al. 2026, recherche sur le “workslop”) ; TechJournal, “Does AI Actually Make You More Productive?”, 2026