Des personnes non-ingénieures travaillent désormais dans votre code source. Voici ce qui se passe réellement.

Le cas d'utilisation semblait modeste. Un grand détaillant australien a commencé à distribuer des licences d'outils de codage IA à son personnel non technique : analystes marketing, responsables des achats. L'idée était simple : leur permettre de poser des questions sur le code source en langage clair et ainsi réduire le nombre d'interruptions subies par les équipes d'ingénierie.

Comment fonctionne le classement dans les résultats de recherche ? Quels facteurs déterminent les recommandations de produits ? Pourquoi le prix de cette référence s'affiche-t-il différemment à deux endroits ?

Le nombre d'interruptions a diminué. C'était prévu. Le reste, en revanche, était inattendu.

Première surprise : le personnel marketing a commencé à déceler des incohérences que l'équipe d'ingénierie n'avait pas remarquées ou qu'elle avait discrètement ignorées. Lorsqu'un analyste peut interroger le code source pour comprendre pourquoi deux catégories de produits ont une logique de prix différente et obtenir une réponse cohérente en quelques secondes, il pose la question. Lorsque la réponse est « parce que ces deux fonctionnalités ont été développées à trois ans d'intervalle par des équipes différentes et n'ont jamais été harmonisées », il remonte l'information. Plusieurs problèmes, qui existaient depuis des années sans que personne du côté métier ne dispose du vocabulaire approprié pour les exprimer précisément, ont ainsi fait surface.

Deuxième surprise : des exigences mieux définies. Les responsables des achats, capables d'examiner la logique des alertes d'inventaire, ont rédigé des cahiers des charges plus précis pour les modifications à apporter à cette logique. Ils connaissaient le fonctionnement actuel du système et savaient exactement ce qu'ils demandaient. Le cycle de clarification entre les équipes métiers et techniques s'en est trouvé considérablement raccourci.

Aucun de ces éléments n'était prévu dans l'analyse de rentabilité.

Puis, il y a eu les imprévus.

L'hypothèse selon laquelle les non-ingénieurs se contenteraient de lire sans écrire s'est avérée fausse. Certains membres du personnel, maîtrisant suffisamment le système pour décrire une modification en langage clair, ont demandé au modèle de générer le code. Certains l'ont soumis sous forme de demandes de fusion. Le processus de revue a détecté la plupart des erreurs, mais a soulevé une question que l'équipe n'avait pas encore abordée : quelle est la politique à suivre concernant le code généré par l'IA et soumis par une personne sans responsabilité technique ?

Il existe également une réelle faille de sécurité. Un outil d'IA ayant accès au code source peut révéler des détails d'implémentation, des structures de données et une logique métier commercialement sensibles. L'accès en lecture via une interface d'IA supervisée est différent d'un accès illimité au dépôt, et cette distinction doit être explicitement prise en compte lors de la conception. Partir du principe que cela est vrai par défaut n'est pas une stratégie de gouvernance.

Les équipes qui gèrent efficacement ce problème l'ont abordé dès le départ comme un problème de conception des accès. Quels systèmes sont concernés ? Que peut révéler le modèle ? Que se passe-t-il lorsqu'une question révèle une information que la personne qui la pose n'était pas censée connaître ? Ces problèmes sont solubles, mais ils exigent la même rigueur que toute autre décision relative au contrôle d'accès.

Ce qui est clair, c'est que la frontière entre les personnes qui comprennent un système et celles qui ne le comprennent pas évolue. Non pas parce que des non-ingénieurs deviennent ingénieurs, mais parce que les outils qui nécessitaient auparavant une expertise en ingénierie pour fonctionner deviennent désormais utilisables sans cette expertise.

La question n'est pas de savoir si cela se produit dans votre organisation. C'est déjà le cas. La question est de savoir si quelqu'un le conçoit.

Ce changement plus global a un nom. Les travaux d'InfoQ sur la décentralisation des décisions architecturales (https://www.infoq.com/news/2026/03/architecture-advice-process/) soutiennent que l'architecture doit se rapprocher des personnes qui la mettent en œuvre, grâce à un processus de conseil structuré plutôt qu'à une centralisation excessive des décisions. Donner aux non-ingénieurs un accès au code source via l'IA constitue, en pratique, un pas dans cette direction, que ce soit intentionnel ou non. Les organisations qui considèrent cela comme une décision architecturale obtiennent généralement de meilleurs résultats que celles qui le perçoivent comme un simple déploiement d'outils.