Pourquoi l'IA ne remplace pas le développement logiciel

La promesse derrière les manchettes

Les assistants de programmation basés sur l'IA peuvent générer du code fonctionnel à partir d'une simple demande en langage courant, en quelques secondes, et cette capacité est bien réelle. Elle alimente naturellement un discours de conseil d'administration : si une machine peut produire du code, le développement logiciel devient une commodité, et on peut réduire le personnel ou le budget en conséquence.

Ce discours saute une étape. Écrire du code et bâtir un logiciel ne sont pas la même chose. Le code est un résultat brut; le logiciel est ce résultat validé contre un problème précis, dans une organisation précise, sous des contraintes précises. L'IA excelle à produire le premier. Elle n'a aucun accès au second.

Ce que l'IA fait vraiment bien

Utilisée correctement, l'IA accélère de façon importante certaines étapes du développement. Elle peut rédiger du code répétitif, traduire une exigence bien définie en code fonctionnel, générer une structure de tests ou proposer plusieurs options d'implémentation pour une fonction donnée. Les équipes qui l'utilisent ainsi livrent plus vite la portion du travail qui était de toute façon mécanique.

Cette valeur est réelle et vaut la peine d'être exploitée. Elle est aussi plus étroite que ce que laissent croire les manchettes : l'IA propose une implémentation, elle ne décide pas si cette implémentation est la bonne pour votre entreprise.

Ce que l'IA ne peut pas faire : définir le problème

Un système d'IA répond au problème qu'on lui soumet. Il n'a aucun moyen de savoir quels compromis comptent pour votre organisation, quels cas limites sont commercialement inacceptables, quelles obligations réglementaires s'appliquent à ces données précises, ou ce que signifie « terminé » pour votre clientèle particulière. Ce travail de définition, la partie la plus exigeante et la plus payante du développement logiciel, revient toujours à des personnes.

Deux entreprises peuvent demander à une IA la même fonctionnalité de gestion d'inventaire et recevoir un code presque identique. Seule celle qui aura correctement précisé ses contraintes, règles de cohérence entre entrepôts, exigences de conservation pour l'audit, traitement d'un solde négatif, obtiendra un logiciel réellement adapté à son entreprise. L'autre obtiendra du code qui compile et qui roule, et qui échouera discrètement la première fois que la réalité ne correspondra pas aux hypothèses que personne n'a formulées.

Où ça dérape, dans les faits

L'échec prend rarement la forme d'une panne spectaculaire. C'est plutôt une accumulation lente de petites décisions prises par défaut plutôt que par choix délibéré.

• Les exigences ambiguës sont tranchées silencieusement à l'intérieur de l'implémentation générée, au lieu d'être renvoyées à l'entreprise pour décision.
• Les cas limites qui comptent vraiment pour l'entreprise ne sont jamais mentionnés dans la demande, donc jamais traités , et ils refont surface d'abord en production.
• Des choix d'architecture s'intègrent invisiblement dans une implémentation plausible, sans que personne n'ait décidé si cette architecture était la bonne à adopter.
• Personne ne valide que la logique générée correspond à la vraie règle d'affaires, jusqu'à ce qu'un client, un auditeur ou un incident force la question.
• La dette technique s'accumule plus vite qu'avant, parce que la génération de code dépasse maintenant la rigueur de révision nécessaire pour la freiner.

La complexité, la variable qui décide du résultat

Le risque de « laisser l'IA proposer l'implémentation » augmente directement avec la complexité de l'environnement où elle opère. Dans une tâche simple et bien délimitée, une hypothèse erronée coûte peu cher à repérer et à corriger. Dans un environnement complexe et interconnecté, la même hypothèse erronée peut se propager pendant des mois avant que quelqu'un ne s'en aperçoive.

Ce n'est pas un problème de code

Plus la complexité augmente , plus de systèmes intégrés, plus de parties prenantes, plus d'exposition réglementaire , plus le nombre de décisions implicites intégrées dans une implémentation augmente aussi. L'IA n'a aucun mécanisme pour savoir lesquelles de ces décisions comptent vraiment pour votre organisation. Elle produira une réponse plausible, peu importe si la bonne question a été posée.

Le jugement d'ingénierie, c'est précisément la discipline qui consiste à faire remonter ces décisions avant qu'elles ne deviennent des défauts : reconnaître quelle exigence est réellement ambiguë, quelle dépendance cédera sous la charge, quel réglage « raisonnable » par défaut entrera en conflit avec la façon dont votre entreprise fonctionne vraiment. Plus l'environnement est complexe, plus ce jugement est ce que vous payez réellement.

Un cadre de référence : où le jugement doit rester dans la boucle

Plutôt que de traiter l'adoption de l'IA comme un choix binaire , remplacer les développeurs ou non , il est plus utile de séparer la livraison logicielle en trois couches et de décider où l'IA s'insère dans chacune.

• Définition du problème : reste entre les mains des personnes qui comprennent l'entreprise, ses contraintes et les conséquences d'une erreur. Non délégable à l'IA.
• Proposition d'implémentation : c'est là que l'IA apporte une vraie accélération , rédaction de code, structure de tests, exploration d'options , sous la direction d'un problème bien défini.
• Jugement de vérification et d'intégration : exige des ingénieurs expérimentés capables d'évaluer si l'implémentation proposée résout réellement le problème défini, à l'intérieur de vos systèmes et contraintes propres.

Les organisations qui fusionnent la deuxième couche avec la première , en laissant l'implémentation de l'IA tenir lieu de définition du problème , sont les plus exposées quand l'environnement se complexifie.

Ce que les PDG et les DAF devraient mesurer

Le « temps jusqu'au premier commit » ou le « nombre de lignes de code générées » sont de mauvais indicateurs pour juger si l'adoption de l'IA fonctionne réellement. Ils mesurent la production, pas l'adéquation. Les dirigeants devraient plutôt suivre des indicateurs qui révèlent si les couches de définition et de jugement suivent le rythme de l'augmentation du code généré.

• Le taux de reprise : la proportion de code assisté par l'IA qui doit être révisée substantiellement après la livraison initiale.
• Les incidents de production attribuables à des exigences floues ou non exprimées, plutôt qu'à des erreurs de code.
• Le temps de révision des ingénieurs seniors comme proportion du temps total de livraison, et s'il diminue plus vite que ce qui est prudent.
• Le temps consacré à la définition et à la spécification du problème avant le début de l'implémentation, comparé au temps consacré à la génération de code.

Repenser le budget d'ingénierie, pas le sabrer

Les organisations qui tirent une vraie valeur de l'IA en développement logiciel ne sont pas celles qui réduisent uniformément leurs effectifs d'ingénierie. Ce sont celles qui en changent la composition , en réorientant l'investissement du travail d'implémentation répétitif vers les personnes capables de définir précisément les problèmes et de juger si une solution proposée convient réellement à un environnement complexe.

Ce virage favorise l'expérience. Le jugement sur les exigences qui sont réellement structurantes, les risques acceptables et les raccourcis qui coûteront cher plus tard se construit par l'exposition à des systèmes complexes dans le temps , ce n'est pas un sous-produit d'une génération de code plus rapide.

La suite des choses

L'IA est un accélérateur réel et grandissant pour la livraison logicielle. Elle ne remplace ni la responsabilité de définir ce qui doit être construit, ni le jugement nécessaire pour vérifier que ce qui est construit tient réellement la route dans un environnement complexe et réel.

Les dirigeants qui tireront le meilleur de l'IA dans ce domaine ne seront pas ceux qui auront éliminé le développement logiciel. Ce seront ceux qui auront gardé le jugement d'ingénierie fermement en place, tout en laissant l'IA faire une plus grande part de la frappe au clavier.