Des workflows adaptés rendent la gouvernance de l’IA plus concrète

Quand le parcours approuvé est plus difficile, les développeurs en créent un autre

Le chemin le plus rapide vers la shadow AI peut commencer par une politique IA elle-même. Les développeurs subissent une pression de livraison et font face à des problèmes d’ingénierie ambigus, donc un assistant utile a une valeur immédiate ; lorsque la voie autorisée est lente, floue ou déconnectée du travail habituel, un ingénieur peut coller des éléments sensibles dans un modèle public ou installer discrètement un assistant de codage non approuvé. Stack Overflow, qui vend des produits et services aux développeurs et a un intérêt commercial dans la manière dont ils adoptent l’IA, indique que 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA. À ce niveau de demande, l’adoption responsable devient un problème de conception des workflows développeur.

Ce problème de workflow apparaît aussi dans le Work Trend Index de Microsoft. Microsoft, grand fournisseur de produits d’IA pour l’entreprise et les développeurs, bénéficie commercialement d’une adoption plus large de l’IA au travail, et son index a constaté un usage généralisé de l’IA de type bring-your-own, ou shadow AI, tandis que beaucoup hésitaient à révéler qu’ils utilisaient l’IA pour un travail important. Les délais d’approbation peuvent rendre ce comportement plus probable lorsqu’ils entrent en conflit avec la pression de livrer. Un processus unique pour des usages présentant des différences matérielles d’accès aux données, d’autonomie et de portée en production peut créer une friction similaire, car les développeurs doivent résoudre eux-mêmes le conflit pratique.

Ce conflit a structuré la récente conversation du podcast Stack Overflow entre Ryan Donovan et Sarah Bird de Microsoft, où la responsabilité a été présentée sous l’angle de l’impact, de la redevabilité et de la conception délibérée du workflow entre les personnes et l’IA. Les conclusions plus larges de Stack Overflow ajoutent une autre contrainte : les développeurs adoptent l’IA tout en restant méfiants vis-à-vis de ce qu’elle produit. Plus de développeurs se méfient de l’exactitude de l’IA qu’ils ne lui font confiance, et leur principale frustration vient d’un résultat qui semble presque correct mais exige un débogage supplémentaire. Une forte demande et une faible confiance font ensemble de la conception du workflow un élément central d’un usage responsable.

La question de la gouvernance commence donc avant même que quelqu’un enfreigne une règle. Les dirigeants doivent se demander si un comportement conforme est rapide, clair et observable, si les contrôles reflètent le risque de la tâche, et si les développeurs peuvent contester un résultat ou faire remonter un problème dans leur workflow habituel. Une politique peut définir la frontière, mais le système d’ingénierie doit rendre cette frontière praticable sous la pression de la livraison.

Traiter la shadow AI comme une télémétrie de gouvernance

Une fois qu’un usage non approuvé apparaît, il peut montrer aux dirigeants où le workflow approuvé a échoué. Cet usage peut toujours créer un risque sérieux en matière de sécurité, de confidentialité ou de fiabilité, mais un incident apporte aussi la preuve d’une demande non satisfaite. La shadow AI peut servir de télémétrie de gouvernance, c’est-à-dire de signaux opérationnels montrant où le processus autorisé crée suffisamment de friction pour que les personnes le contournent. Ce signal peut transformer une violation en source d’information pour améliorer le système, tout en mettant fin à l’usage non sûr.

L’exploitation de ce signal commence par le travail que les développeurs essayaient d’accomplir. Les équipes peuvent identifier quelles tâches poussent les personnes vers des outils externes, repérer la friction dans l’alternative approuvée, et déterminer si l’élément manquant est la donnée, le contexte pertinent, une intégration ou une autorisation. Cette séquence distingue une restriction nécessaire d’un obstacle de processus évitable. Elle donne aussi aux équipes plateforme et sécurité un travail d’ingénierie concret.

Ces obstacles peuvent guider la conception d’une infrastructure approuvée. Stack Overflow a évoqué des passerelles supervisées et des plateformes d’IA approuvées comme moyens de permettre aux développeurs d’expérimenter via une infrastructure visible, une approche alignée sur son intérêt commercial pour les workflows développeur et l’adoption de l’IA. Une telle infrastructure donne à l’organisation un point d’application des contrôles tout en laissant aux développeurs des capacités utiles. Un service approuvé efficace leur fournit un contexte pertinent, un accès simple, des limites compréhensibles et une voie d’escalade rapide lorsque les règles ordinaires ne correspondent pas à la tâche.

Ces choix d’accès comptent, car une charge d’approbation excessive peut accroître les délais sans amélioration correspondante de la sécurité. Les développeurs sous pression peuvent alors éviter le processus officiel, dissimuler des expérimentations ou choisir des outils facilement disponibles en dehors des contrôles de l’organisation. La gouvernance perd alors de la visibilité précisément là où elle en a le plus besoin. Une enquête sur l’usage caché devrait demander quelle partie du workflow a rendu utile, aux yeux des utilisateurs, le fait de cacher ou de contourner le système.

Cette approche diagnostique permet toujours à une organisation d’arrêter immédiatement un comportement non sûr. En même temps, l’organisation peut se demander ce que l’incident révèle du parcours autorisé et utiliser la réponse pour ajuster l’accès, les autorisations, les intégrations et l’escalade. La gouvernance peut alors apprendre à partir de la demande observée avant que la même pression ne produise un autre contournement caché.

Intégrer la gouvernance dans le parcours d’ingénierie

Corriger ces échecs de workflow exige que la politique devienne une interface d’ingénierie : un ensemble de décisions que les développeurs peuvent appliquer pendant qu’ils travaillent. Le framework de gestion des risques liés à l’IA du NIST organise la tâche autour de quatre fonctions, Govern, Map, Measure et Manage, en traitant la gouvernance comme une activité opérationnelle continue. Pour une équipe d’ingénierie, cela signifie classifier le cas d’usage, préciser les modèles et sources de données autorisés, établir des tests, identifier le responsable de l’approbation et décider quelles preuves doivent rester dans l’historique de développement.

Ces classifications doivent répondre aux questions au moment où un développeur y est confronté. La politique doit établir quelles données peuvent entrer dans un outil approuvé, à quels dépôts et systèmes cet outil peut accéder, quelle revue s’applique au code généré et quelles décisions restent du ressort d’un humain. Elle doit aussi prévoir une réponse définie aux résultats nuisibles, non sécurisés ou peu fiables, ainsi qu’un seuil à partir duquel une expérimentation devient un système de production. Le travail courant doit donner aux développeurs suffisamment d’informations pour prendre ces décisions sans devoir organiser une réunion de comité.

Des réponses claires réduisent aussi l’incertitude pendant l’adoption. Les conclusions de Stack Overflow sur l’adoption des technologies identifient la sécurité et la confidentialité comme les principales raisons pour lesquelles les développeurs rejettent une technologie, un constat lié à l’intérêt commercial de l’entreprise dans l’usage des technologies par les développeurs. Les règles opérationnelles répondent à cette préoccupation lorsqu’elles indiquent à un ingénieur ce qui peut être fait en toute sécurité et ce qui exige une escalade. La gouvernance devient alors une partie du processus de décision du développeur sous contrainte de temps.

Ces décisions ont besoin de points d’application là où les actions d’ingénierie deviennent des changements durables : dépôts, pull requests, pipelines de build, systèmes d’accès et workflows de déploiement. Les recommandations du NIST pour un développement sécurisé de l’IA étendent les pratiques de sécurité logicielle à l’ensemble du cycle de développement. Appliquée à l’IA d’entreprise, cette approche peut placer les configurations de modèles approuvées sous contrôle de version, restreindre l’accès selon le rôle, analyser les prompts et les résultats à la recherche de secrets, conserver des logs pour les usages à plus haut risque et exiger des tests avant que des changements générés par l’IA puissent être fusionnés.

Ces points d’application rendent aussi la revue humaine plus précise. GitHub, qui vend des outils d’IA pour développeurs et bénéficie donc du fait que les développeurs puissent utiliser avec succès des systèmes de codage par IA, recommande des vérifications fonctionnelles, une validation par rapport au contexte pertinent, une revue des dépendances, une revue collaborative et de l’automatisation lorsque c’est approprié dans le cadre de la supervision humaine du code généré par l’IA. Ces vérifications transforment l’instruction vague consistant à « examiner le résultat de l’IA » en travail d’ingénierie défini. Une pull request peut contenir à la fois le changement généré et les éléments de preuve nécessaires pour décider si ce changement a sa place dans le système.

Une revue spécifique est importante parce que l’IA ajoute des modes de défaillance que la revue de code ordinaire doit savoir reconnaître. Les catégories de risque de l’IA générative d’OWASP incluent l’injection de prompt, la divulgation d’informations sensibles, les faiblesses de la supply chain, la mauvaise gestion des résultats et une agentivité excessive, lorsqu’un système a plus de capacité d’action que sa tâche ne l’exige en toute sécurité. Ces risques affectent les contrôles autour des entrées, des sorties, des dépendances, des autorisations et des actions. La compilation seule ne permet pas d’établir si le code généré peut être utilisé en toute sécurité.

La même logique de cycle de vie traverse différents types de recommandations. Les principes secure-by-design de la CISA placent la responsabilité dans la conception du produit, tandis que le NIST fournit des frameworks de risque et de développement, OWASP identifie les catégories de défaillance de l’IA générative, et GitHub transforme la supervision humaine en pratiques de revue concrètes. Ensemble, ces ressources soutiennent une approche d’ingénierie dans laquelle les développeurs rencontrent la gouvernance à travers les systèmes où ils demandent un accès, écrivent du code, examinent des changements, exécutent des tests et déploient des logiciels.

Rendre le parcours rapide plus strict à mesure que le risque augmente

Une fois la gouvernance intégrée dans ces systèmes, un accès approuvé plus simple peut coexister avec un contrôle fort. Un parcours bien conçu peut supprimer les attentes inutiles tout en appliquant plus régulièrement qu’un processus d’approbation informel l’accès fondé sur les rôles, l’analyse des secrets, la journalisation, les tests, la revue humaine, l’escalade et la supervision de la production. La question de conception clé est le niveau de contrôle requis pour chaque usage.

Ce niveau doit suivre le cas d’usage. Demander à un système d’IA d’expliquer du code présente un profil de risque très différent de celui qui consiste à donner à un agent un accès en écriture à des systèmes de production, car le second cas a une plus grande autonomie et peut modifier directement un environnement opérationnel. Appliquer la même charge d’approbation aux deux consomme de la capacité de revue tout en accordant un poids insuffisant à leurs conséquences différentes. La gradation du risque maintient la rapidité pour les cas à faibles conséquences et réserve un examen plus strict aux actions capables de provoquer des défaillances plus importantes.

Quatre dimensions fournissent une base pratique pour cette gradation : la sensibilité des données, l’autonomie, la portée et la réversibilité. Des données plus sensibles justifient des contrôles d’accès et de traitement plus stricts ; une plus grande autonomie appelle des contraintes plus fortes sur ce que le système peut faire ; une portée plus large augmente le nombre d’utilisateurs ou de systèmes exposés à une erreur ; et une faible réversibilité accroît le coût de récupération. Ces dimensions donnent aux équipes d’ingénierie et de sécurité une classification pratique pour chaque usage de l’IA.

Cette classification détermine comment les contrôles se renforcent. Les autorisations fondées sur les rôles limitent qui peut invoquer des fonctions à plus haut risque, l’analyse des secrets réduit l’exposition accidentelle, et une journalisation plus poussée pour les usages à plus haut risque conserve les preuves nécessaires à l’enquête et à la revue. Les tests avant fusion et une responsabilité humaine explicite encadrent les changements logiciels générés, tandis que les voies d’escalade traitent les cas incertains. Une fois que le comportement de l’IA atteint la production, la supervision ajoute un autre contrôle, et la revue devient progressivement plus stricte à mesure que la sensibilité, l’autonomie, la portée ou la difficulté de retour en arrière augmentent.

La gradation du risque clarifie aussi ce que signifie la supervision humaine pour les outils développeur. GitHub conseille aux utilisateurs de traiter GitHub Copilot « comme un outil plutôt que comme un remplacement » et de revoir et valider ses réponses générées ; GitHub a un intérêt commercial dans l’adoption réussie de Copilot. Cette recommandation maintient la responsabilité du développeur sur la décision d’ingénierie finale même lorsque la génération est rapide. Le workflow soutient cette responsabilité en fournissant le contexte, les tests, les étapes de revue et les autorisations nécessaires à une validation pratique.

Parce que les contrôles suivent une classification connue, un parcours plus strict pour les cas à haut risque peut malgré tout rester efficace. Les équipes peuvent concevoir les tests, conserver les preuves requises, désigner le responsable et impliquer les spécialistes sécurité ou confidentialité pendant le développement, avant que le travail n’arrive à l’approbation finale. La rapidité vient alors de la suppression de l’incertitude et des transferts répétés, tout en maintenant le niveau d’exigence appliqué aux systèmes à conséquences importantes.

Donner à chaque workflow IA un responsable humain, et rendre les défaillances signalables

Les contrôles gradués selon le risque ont toujours besoin de quelqu’un qui porte la responsabilité du résultat. Des termes comme assistant, collaborateur et agent peuvent décrire la manière dont le logiciel se comporte, mais la responsabilité organisationnelle reste humaine ; chaque cas d’usage de l’IA a donc besoin d’un responsable nommé qui comprend le résultat visé et a l’autorité pour arrêter ou modifier le processus. Ce responsable définit la performance acceptable, décide où le jugement humain doit intervenir et s’assure qu’une défaillance entraîne une réponse.

Cette responsabilité doit perdurer, car le Generative AI Profile du NIST répartit la gestion des risques sur la conception, le développement, l’usage et l’évaluation. Les responsables produit portent la décision métier, tandis que les responsables de l’ingénierie portent la qualité de mise en œuvre et les spécialistes sécurité et confidentialité portent les contrôles relevant de leurs domaines. Les développeurs restent responsables du code qu’ils soumettent, les reviewers des décisions d’approbation, et les opérateurs de la supervision de la production et de la réponse aux incidents. Cette répartition donne à chaque étape une personne responsable lorsque des conséquences apparaissent.

La responsabilité ne fonctionne que si les signaux importants peuvent atteindre le responsable. Un développeur peut d’abord voir un problème sous la forme d’un contexte divulgué, d’une dépendance inventée, d’une incitation à produire du code non sécurisé, d’une complétion étrange, d’un package suspect, d’un chemin de données non documenté ou d’un résultat plausible en apparence mais contredisant la connaissance métier. Ces signaux peuvent sembler mineurs avant que leur cause ou leur portée ne soient connues. Le signalement précoce devient donc une partie de la gestion du risque opérationnel.

Ce signalement dépend en partie des conditions de l’équipe. Le Project Aristotle de Google a identifié la sécurité psychologique comme la dynamique la plus importante dans son étude des équipes efficaces, et Google décrit un tel environnement comme un cadre dans lequel les personnes peuvent prendre des risques interpersonnels, poser des questions et faire remonter des erreurs. Pour les systèmes d’IA, cette propriété a une conséquence technique directe, car les signaux faibles deviennent visibles plus tôt lorsque les développeurs peuvent contester un outil, une hypothèse ou un processus approuvé sans s’attendre à ce que le simple fait de signaler joue contre eux.

Les recherches DORA établissent de la même manière un lien entre des cultures de livraison logicielle psychologiquement sûres et de meilleures performances ainsi qu’une plus grande résilience. Les managers peuvent affaiblir ce mécanisme lorsque des objectifs d’adoption font paraître la remise en question d’un outil d’IA comme une forme de résistance. Après une défaillance, les questions utiles portent sur ce qui a échoué, sur la manière dont le workflow a encouragé l’erreur, et sur la protection qui réduirait la probabilité ou les conséquences d’une récurrence. Demander pourquoi un développeur « a fait confiance à l’IA » personnalise l’échec et peut signaler que soulever la prochaine alerte comporte un risque personnel.

Parce que les contrôles automatisés détectent des schémas connus, les ingénieurs et experts métier ont toujours besoin d’un canal pour signaler un comportement suspect qui n’entre dans aucune règle existante. Une culture du signalement fournit ce canal, transformant les observations en action d’ingénierie. Les responsables peuvent alors ajuster les autorisations, les tests, les modèles, les exigences de revue ou le workflow lui-même.

Former aux décisions que les développeurs prennent réellement

Une fois la responsabilité et l’escalade en place, la formation doit préparer les développeurs à les utiliser dans de vraies décisions d’ingénierie. L’analyse de Stack Overflow sur la confiance des développeurs considère l’usage efficace de l’IA comme une compétence impliquant la structure des prompts, l’évaluation des résultats et l’intégration du code généré dans les systèmes existants, dans le cadre de l’intérêt commercial plus large de l’entreprise pour la manière dont les développeurs utilisent la technologie. Cette compétence est importante parce que les développeurs signalent déjà à la fois une faible confiance dans l’exactitude de l’IA et un travail de débogage causé par des résultats presque justes. La formation doit donc préparer les personnes à vérifier les résultats dans le cadre même de la tâche.

Cette préparation devrait fonctionner davantage comme une habilitation à utiliser le système que comme une présentation générique de sensibilisation. Les développeurs doivent savoir quels outils sont approuvés, quelles données ces outils peuvent recevoir, quelles défaillances courantes attendre, quelle revue est requise et où faire remonter un cas incertain. Des exemples propres à l’organisation peuvent ensuite transformer ces règles en décisions ressemblant au travail que les personnes auront réellement à effectuer.

Ces décisions diffèrent selon les rôles, donc la pratique doit différer elle aussi. Les ingénieurs backend ont besoin d’expérience dans la revue de migrations de base de données générées, de logique d’authentification et de dépendances ; les data engineers doivent protéger les enregistrements sensibles et valider les transformations. Les managers d’ingénierie ont besoin de critères pour déterminer quand un projet pilote exige une revue sécurité, juridique ou architecture, tandis que les équipes plateforme doivent observer le comportement des agents et contraindre les autorisations. Une formation spécifique au rôle place chaque décision dans le groupe capable d’en influencer le risque.

La pratique peut aussi suivre la manière dont les développeurs apprennent déjà. Les conclusions de Stack Overflow sur l’apprentissage montrent que les développeurs développent leurs compétences en IA à travers de multiples ressources, y compris les outils enrichis par l’IA eux-mêmes. Les organisations peuvent tirer parti de ce comportement au moyen d’exercices en sandbox, de résultats volontairement défectueux, d’exemples de prompts acceptables et de modèles internes réutilisables. La pratique sur les erreurs est particulièrement utile, car elle développe la capacité à reconnaître les résultats presque corrects qui créent un travail supplémentaire de débogage et de vérification.

Comme la pratique a une fin, les recommandations utiles doivent rester dans l’environnement d’ingénierie. Les instructions de dépôt peuvent établir des règles locales, les checklists de revue peuvent rendre l’évaluation répétable, des suites de tests réutilisables peuvent détecter des défaillances récurrentes, et des modèles de prompts approuvés ainsi que des exemples documentés peuvent réduire l’improvisation. Les feuilles de présence montrent qu’une session a eu lieu, tandis que ces artefacts continuent d’orienter les décisions d’ingénierie ultérieures.

Mesurer les résultats des équipes

Une fois ces workflows formés en fonctionnement, les seuls chiffres d’adoption ne peuvent toujours pas montrer s’ils fonctionnent bien. Les licences attribuées, les prompts soumis et les utilisateurs actifs hebdomadaires mesurent l’activité, tandis que la valeur d’ingénierie dépend de la qualité, de la vitesse, du risque et du travail porté par l’ensemble de l’équipe. Un chiffre d’usage en hausse peut coexister avec davantage de corrections, de revue ou de problèmes en production ; la mesure doit donc suivre le résultat d’ingénierie.

Les recherches DORA de 2024 montrent pourquoi une mesure plus large est nécessaire. Une adoption plus élevée de l’IA était corrélée à des améliorations de la qualité de la documentation, de la qualité du code et de la vitesse de revue, tandis que la recherche identifiait aussi de possibles effets négatifs sur la performance de livraison logicielle. Ces résultats contrastés signifient que la productivité individuelle ou l’adoption ne peuvent pas tenir lieu de performance du système. L’unité pertinente est un workflow défini et ses résultats avant et après l’introduction de l’IA.

Un workflow défini permet aux équipes de mesurer le temps de cycle, les défauts échappés, le taux de rollback, les constats de sécurité, la charge de revue, la qualité de la documentation, le volume d’incidents, la satisfaction des développeurs et le temps passé à corriger les résultats de l’IA. Le sous-ensemble utile dépend de la tâche et de ses risques, mais la mesure doit suivre le travail suffisamment loin pour exposer les coûts transférés. Un résultat presque correct peut faire gagner du temps de génération tout en ajoutant du débogage, et un changement local rapide peut créer du travail de revue ou de maintenance ailleurs.

Ce travail en aval est également visible dans l’enquête de Stack Overflow sur les agents, menée par une entreprise ayant un intérêt commercial dans l’usage de l’IA par les développeurs. Les agents indiquent des gains de productivité individuelle sans gains correspondants en collaboration d’équipe. Un ingénieur peut donc terminer une tâche plus vite pendant que ses collègues absorbent l’effort de vérification, d’intégration ou de maintenance. Une mesure responsable inclut ce travail en aval afin qu’un gain local apparent soit jugé à l’aune de son effet sur l’organisation d’ingénierie.

Suivre le travail à travers ces frontières rend aussi le parcours approuvé lui-même mesurable. Les dirigeants peuvent voir si un contexte utile et un accès simple réduisent l’incitation à utiliser des outils cachés, si les contrôles évoluent avec la sensibilité des données, l’autonomie, la portée et la réversibilité, et si les voies de signalement font remonter les problèmes assez tôt pour que les responsables puissent agir. Ces résultats montrent si la gouvernance fonctionne à l’intérieur de l’accès, des dépôts, des revues, des tests, du déploiement, de la supervision, de la responsabilité et de l’escalade, c’est-à-dire aux endroits où les développeurs prennent réellement des décisions importantes.

En résumé

L’adoption responsable de l’IA est en fin de compte une décision de modèle opérationnel, et pas seulement une décision de politique. Les développeurs utiliseront l’IA là où elle les aide à livrer, et la gouvernance sera la plus efficace lorsque le parcours approuvé correspondra à cette réalité. Les dirigeants doivent donc rendre l’usage sûr plus facile à identifier, à obtenir et à suivre, tout en réservant des contrôles plus lourds aux systèmes présentant une plus grande sensibilité, autonomie, portée ou difficulté de retour en arrière.

Cela exige une coordination entre la direction de l’ingénierie, de la sécurité, de la confidentialité, du produit et de la plateforme. La shadow AI doit éclairer les points où les workflows approuvés doivent être améliorés ; les usages à plus haut risque doivent avoir des responsables humains clairement identifiés ; et le signalement, la formation, la revue et la supervision doivent exister à l’intérieur des systèmes où le travail se déroule déjà. Les contrôles qui dépendent du fait que les développeurs quittent leur workflow pour interpréter une politique sont moins utiles sous la pression de la livraison.

La mesure de progrès au niveau de la direction générale ne devrait pas se limiter à l’adoption de l’IA. Les dirigeants doivent savoir si l’IA améliore la livraison sans transférer des coûts cachés vers le débogage, la revue, les incidents de sécurité ou la maintenance. Lorsque les organisations mesurent ces résultats et les utilisent pour affiner le parcours approuvé, la gouvernance devient une partie du fonctionnement de l’ingénierie plutôt qu’un processus séparé que les développeurs doivent contourner.