L'IA n'est pas qu'un outil, c'est votre nouveau coéquipier : de l'influence sociale à la transparence

Chez Nexapp, on répète souvent que la technologie doit servir l'humain. Depuis l'arrivée massive des modèles de fondation (LLM) dans nos environnements de développement, la discussion dans le monde du développement logiciel tourne souvent autour des gains de performances : quelle quantité de code peut être générée? À quelle vitesse?

Mais si l'on examine les recherches récentes et nos propres expérimentations à l'interne, on constate que l'intégration de l'IA constitue un changement fondamental de la dynamique d'équipe. L'intelligence artificielle n'est plus seulement un outil passif ; elle devient un coéquipier artificiel qui exerce une influence sociale réelle sur les développeurs.

Pour qu'une équipe Humain-IA fonctionne efficacement sans créer de dette technique ni de dette cognitive, il faut comprendre comment cette collaboration fonctionne vraiment. Quelles sont les forces en présence qui empêcheraient cette collaboration? Ou mieux, qui la renforceraient?

Une adaptation invisible mais rapide

Qu'on le veuille ou non, nos comportements changent au contact de l'IA. C'est ce que la recherche appelle l'influence sociale normative. Les études montrent que les humains ajustent instinctivement leur style de travail pour qu'il soit complémentaire à celui de l'IA.

Une étude de l’Université Clemson (Flathmann et al., 2024) montre que nous adaptons rapidement notre rôle pour devenir complémentaires d’une IA : dans une partie de Rocket League, face à une IA “agressive”, l’humain se replie ; face à une IA plus prudente, il reprend l’initiative.

En développement logiciel, c'est pareil. Cette “agressivité” vient souvent du cadre que l’on donne à l’IA. Si on la laisse produire des changements et qu’on se contente de répondre aux questions, on bascule en posture défensive/réactive : on corrige et on valide après coup. Ça peut être très efficace pour une preuve de concept.
Mais pour du code critique, on veut l’inverse : reprendre le lead en amont (specs, contraintes, tests, découpage) et forcer l’IA à jouer sous notre contrôle.

Et c'est une excellente nouvelle! Nous sommes câblés pour collaborer, mais surtout pour nous adapter. Ce n’est pas Darwin qui vous dira le contraire!

Mais attention! L'étude démontre aussi que si l'IA est perçue comme disruptive, si elle "vole le ballon" ou brise le flow sans raison, l'humain aura tendance à abdiquer, à se désengager et à laisser la machine continuer sans lui. À laisser le contrôle.

Lâcher prise en gardant la main

Pour qu'une équipe Humain-IA fonctionne, l'humain doit ressentir un sentiment de contrôle. C'est paradoxal, mais pour accepter de déléguer une tâche complexe à une IA, le développeur doit savoir qu'il peut "tirer la plug" ou opposer son veto à tout moment.

Comme le mentionnait un collègue, Dominique Richard, lors d'une discussion interne : «La qualité du code de ton IA est à la hauteur du dev qui la dirige.» Si le développeur perd le contrôle de ce que l'IA génère, on tombe dans une spirale où l'IA devient une équipière incompétente qui produit du code tout au plus médiocre, voire mauvais et dangereux.

Conseil : Instaurez des mécanismes de veto clairs. L'IA propose ; l'humain dispose. C'est la base pour éviter ce que les chercheurs appellent la «déqualification cognitive», c'est-à-dire la perte de ses compétences à force de délégation. Ou encore la dépendance à l'IA.

Le piège du confort de la dépendance

C'est l'éléphant dans la pièce. À force d'avoir un copilote ultra-compétent qui gère l'analyse des informations et le support décisionnel, on glisse tranquillement vers une dépendance cognitive. Au début, c'est magique : moins de charge mentale, plus de vitesse. Mais le risque à long terme, c'est l'atrophie des compétences.

C'est le syndrome du GPS : à force de suivre aveuglément la ligne bleue, on finit par ne plus savoir s'orienter dans sa propre ville (ou dans sa propre architecture logicielle). Cela ouvre la porte toute grande au biais d'automatisation.

GPS montrant le chemin sur un téléphone intelligent dans une voiture en marche.

Dans le développement logiciel, ce biais est un piège cognitif redoutable : l'IA génère du code qui a l'apparence de la compétence (syntaxe parfaite, formatage propre, architecture qui fait du sens), ce qui nous amène à confondre la plausibilité et l'exactitude. Face à une solution qui “sonne vraie”, le développeur baisse sa garde et appuie sur "Enter" par réflexe de validation plutôt que par conviction logique. Plus on accepte sans questionner, plus le réflexe se renforce et plus on perd le muscle mental nécessaire pour résoudre les problèmes complexes lorsque la machine échoue.

Pour y remédier, il faut impérativement remettre l'humain dans la boucle. Non pas en ralentissant le travail, mais en changeant la nature de l'interaction avec l'outil : on passe d'une confiance aveugle à une collaboration critique.

Au-delà du code : explicabilité vs transparence sociale

C'est ici que la plupart des équipes font fausse route. On pense souvent qu'il suffit que l'IA explique comment elle est arrivée à une réponse pour qu'on lui fasse confiance. C'est ce qu'on appelle l’explicabilité technique.

Mais pour collaborer efficacement, l’explicabilité technique ne suffit pas. Vos équipes ont besoin de transparence sociale.

Quelle est la différence?

L'explicabilité technique (Comment) : L'IA vous dit : «J'ai généré ce code en me basant sur une source X et avec un niveau de confiance de Y %». C'est utile, mais ça ne dit pas grand-chose sur la pertinence et l’intention.
La transparence sociale (Pourquoi) : L'IA contextualise son action : «J'ai refactorisé ce module pour respecter l'architecture hexagonale du projet, mais je n'ai pas touché à la base de données, car je n'ai pas les accès requis par les normes de sécurité.»

La transparence sociale est l’un des éléments qui modulent le niveau de confiance des développeurs envers l’IA tout en laissant de la place à leur esprit critique.

Quand le doute apporte de la valeur

L'objectif de la transparence sociale n'est pas de maximiser la confiance aveugle (ce qui mène à des erreurs coûteuses ou à des biais d'automatisation), mais de cultiver un scepticisme sain. En expliquant son procédé et ses intentions, l'IA permet au développeur de savoir exactement quand il doit intervenir.

Demander à l’IA de générer un plan ou des diagrammes avant ou pendant la phase d’implémentation est une forme de transparence sociale pilotée par le développeur : cela force l’IA à exposer sa compréhension du «flow» et des règles d’affaires avant d’exécuter la tâche. C’est ça, le scepticisme sain.

Traiter l'IA comme un nouveau joueur

Comment appliquer ces principes lundi matin? Même si l’IA ne peut pas être considérée comme un membre de l’équipe, une approche recommandée consiste à la traiter comme un nouveau membre à former et à surveiller.

Le "Shadowing" avant l'embauche

Avant de déployer un agent IA massivement, laissez vos équipes l'observer en action ou encore l'expérimenter sur des projets pilotes. C'est comme une entrevue technique pour votre IA : on analyse comment elle se comporte pour l’intégrer au mieux dans l'équipe.

Bien coder pour mieux régner

L'IA n'apprend pas vraiment au sens humain. Elle a besoin d'un contexte frais. Gardez une architecture propre, un code clair et forcez l'IA à se référer à votre documentation, votre "source de vérité", qu'il s'agisse de documents ou de suites de tests, peu importe. Cela pour éviter qu'elle n'hallucine ou ne dégrade la qualité du code à force de se relire elle-même. Tout comme un nouvel arrivant a besoin d'un contexte clair avant de se lancer.

Valider l'intention

Utilisez la transparence sociale. Lors de l'arrivée d’un nouveau membre dans l'équipe, on a tout intérêt à ce qu’il exprime son schéma de pensée afin de favoriser l’alignement des membres.

Restez le pilote

L'avenir du développement logiciel est une collaboration hybride où l'IA exerce une influence sociale indéniable. Elle peut accroître la productivité ou entraîner une dette technique massive si elle est mal gérée.

Au cours de cette transition, le leadership joue un rôle déterminant. Les leaders ne sont pas de simples spectateurs : ils sont les architectes de cette collaboration humain-IA. Leur responsabilité est double.

D'abord, choisir les bons outils. Toutes les IA ne se valent pas et toutes ne conviennent pas à votre contexte. On ne choisit pas celles qui font le plus de bruit sur LinkedIn. Tendre à ne pas être dépendant d’un fournisseur est également un idéal pertinent afin de garder le contrôle.

Ensuite, faciliter la transition de l'outil au coéquipier. L'IA ne communique pas explicitement ses limites. C'est au leader de cultiver la transparence nécessaire et d'aider l'équipe à développer une confiance calibrée : ni aveugle ni méfiante.

Concrètement, cela signifie rester informé des avancées technologiques, et surtout, créer les conditions pour que les humains et les agents intelligents se comprennent et se coordonnent efficacement.

La différence entre le succès et l’échec réside dans la gouvernance. Ne laissez pas l'IA devenir un exécutant opaque. Utilisez-la pour augmenter vos capacités, mais assurez-vous que les développeurs gardent les mains sur le volant (et les yeux sur la route). L'imputabilité des développeurs à leur code n'a jamais eu plus de sens.

Après tout, l'IA ne fait que répéter ce qu'elle a vu.

Assurons-nous de lui montrer l'exemple de l'excellence.