IA, code et design : pourquoi le plus important n’a pas changé

Les outils d’IA savent écrire du code. Mais pourquoi le cœur du design logiciel reste un modèle mental humain, et ce que cela implique vraiment.

I. Introduction  

Les assistants de codage basés sur l’IA sont aujourd’hui capables de produire :

• du code syntaxiquement valide,
• du code fonctionnel,
• et même une certaine forme de raisonnement sur la structure du code.

Face à cela, une question légitime se pose :
faut-il encore apprendre à coder, ou suffit-il d’apprendre le design et de laisser le reste à l’IA ?

Cette question est au cœur d’une vidéo intitulé ‘The Skill That Separates Good Developers from GREAT Ones ‘de Emily Bache, qui propose une réponse nuancée, profondément ancrée dans les fondamentaux de l’ingénierie logicielle.

II. En logiciel, le code est le design  

Un point central rappelé dans la vidéo est que, contrairement à d’autres disciplines d’ingénierie, le logiciel ne sépare pas clairement :

• la phase de conception,
• et la phase de production.

Le code source est le design du logiciel.

Une fois écrit :

• il est interprété de manière déterministe,
• il peut être reproduit sans ambiguïté,
• il ne nécessite plus d’intervention du concepteur pour être “fabriqué”.

Le compilateur et la chaîne de build jouent le rôle de l’usine.
Le design, lui, réside dans le code.

III. Écrire du code, tester et déboguer font partie du design  

Dans cette perspective, coder n’est pas une activité mécanique.
C’est une activité de conception.

Les tests et le débogage ne sont pas des étapes annexes :

• ils servent à évaluer le design,
• à révéler ses faiblesses,
• à le corriger et l’affiner.

Il n’est donc pas cohérent d’opposer apprentissage du code et apprentissage du design :
apprendre à coder, c’est apprendre à concevoir.

IV. Programmer, c’est construire une théorie  

Emily Bache s’appuie sur les travaux de Peter Naur, qui décrivait la programmation comme une activité de construction de théorie.

Cette théorie correspond à :

• une compréhension cohérente du système,
• la capacité à expliquer pourquoi chaque partie existe,
• la capacité à répondre à des questions sur le code,
• et surtout, la capacité à le modifier correctement.

Le design ne se limite donc pas à ce qui est stocké dans un dépôt Git.
Il inclut ce qui se trouve dans la tête des personnes qui travaillent sur le logiciel.

V. Le coût du logiciel est le coût du changement  

Un autre point fondamental abordé dans la vidéo est l’équivalence de Constantine, popularisée par Kent Beck :

Le coût du logiciel est essentiellement égal au coût de le faire évoluer.

Ce coût dépend fortement :

• du niveau de couplage,
• de la clarté du design,
• de la charge cognitive nécessaire pour comprendre le système.

Plus un système est difficile à tenir mentalement, plus il est coûteux à modifier.

VI. Où se situe réellement l’IA dans ce processus  

Les outils d’IA savent produire du code à partir :

• d’instructions en langage naturel,
• de contraintes,
• de tests,
• de règles de conception.

Ils peuvent générer une solution fonctionnelle.
Ils participent donc, dans une certaine mesure, à la conception du code.

Mais un point essentiel demeure :
la théorie du système ne s’insère pas automatiquement dans la tête du développeur.

Ce que le développeur possède réellement, c’est :

• le contenu des prompts,
• pas nécessairement la compréhension profonde du code généré.

VII. Modifier du code généré par une IA pose la même question fondamentale  

Lorsque vient le moment de faire évoluer un système généré par une IA, deux options existent :

• continuer à modifier uniquement les prompts,
• ou lire, analyser et comprendre le code produit.

Dans le second cas, le développeur doit reconstruire le même modèle mental que pour du code écrit par un autre humain :

• comprendre comment le système fonctionne,
• identifier ses abstractions,
• juger de sa qualité,
• et imaginer comment il pourrait évoluer.

Comme l’a formulé Martin Fowler :

« N’importe qui peut écrire du code qu’un ordinateur comprend.
Les bons développeurs écrivent du code que les humains comprennent. »

Cette remarque reste valable, même à l’ère de l’IA.

VIII. Élever le niveau d’abstraction : une possibilité, pas une solution universelle  

La vidéo évoque des cas où des équipes utilisent l’IA comme une sorte de “compilateur avancé”, en programmant principalement via des prompts et des descriptions textuelles.

Dans ces situations :

• le niveau d’abstraction est élevé,
• la théorie du système est exprimée en langage naturel,
• le langage d’implémentation devient secondaire.

Cette approche peut fonctionner dans certains contextes, mais elle soulève des questions importantes de passage à l’échelle, de cohérence et de maintenabilité à long terme.

IX. Les compétences nécessaires n’ont pas changé  

Un constat central de la vidéo est que les compétences requises pour obtenir de bons résultats avec l’IA sont les mêmes que celles nécessaires sans elle :

• compréhension du domaine,
• clarté du raisonnement,
• sens du design,
• capacité à réduire le couplage.

L’IA n’élimine pas le besoin de design.
Elle rend même cette compétence encore plus visible.

X. Faut-il encore apprendre à coder ?  

La conclusion d’Emily Bache est claire.

Puisque :

• tout code est du design,
• et qu’une partie essentielle du design n’est pas dans le code mais dans le modèle mental,

alors apprendre à coder reste fondamental, en particulier en début de carrière.
C’est par l’expérience de l’écriture de code que l’on apprend à concevoir.

Les techniques de prompting évolueront rapidement.
Les compétences de design, elles, resteront toujours nécessaires.

XII. Conclusion  

L’IA change la manière dont nous écrivons du code,
mais elle ne change pas ce qui fait la valeur d’un bon ingénieur logiciel.

Le design reste une activité humaine,
car il repose sur la compréhension, le jugement
et la capacité à faire évoluer un système dans le temps.

Le code peut être généré.
La théorie du système, elle, doit toujours être construite.

Liens utiles  

• The Skill That Separates Good Developers from GREAT Ones Vidéo à l’origine de cet article, qui explore le lien entre code, design, modèle mental et usage des outils d’IA.
• Tidy First? et travaux sur le coût du changement Livre récent de Kent Bec. Réflexions autour de l’équivalence de Constantine et de l’importance du design pour réduire le coût d’évolution des logiciels.