Développer avec l’IA : ce qui change, ce qui reste, et ce qui devient critique

Les outils d’IA écrivent du code rapidement. Mais quelles compétences deviennent réellement centrales quand le code n’est plus rare ?

I. Introduction  

Les assistants de codage basés sur l’IA ont profondément modifié le quotidien des développeurs.
Ils génèrent du code fonctionnel en quelques secondes, proposent des implémentations complètes et réduisent fortement le temps passé sur des tâches répétitives.

Cette évolution soulève une question centrale :

Si le code peut être produit facilement, où se situe désormais la valeur du développeur ?

Pour y répondre, il faut observer non pas ce que l’IA sait faire, mais ce qu’elle ne prend pas en charge.

II. Le code n’est plus rare, mais le jugement l’est  

Pendant longtemps, écrire du code correct était coûteux :

• en temps,
• en attention,
• en effort cognitif.

L’IA a radicalement réduit ce coût.
Mais elle n’a pas réduit : le nombre de décisions à prendre ni la responsabilité associée à ces décisions.

Choisir une solution n’est pas la même chose que la produire. C’est précisément là que se situe désormais la valeur.

Chaque ligne de code générée implique encore :

• un choix de structure,
• un découpage de responsabilités,
• un compromis implicite.

L’IA peut proposer des solutions,mais elle ne peut pas porter la responsabilité de leurs conséquences à long terme.

Le rôle du développeur se déplace donc :

• de l’exécution vers l’arbitrage,
• de la production vers l’évaluation,
• de la vitesse vers la pertinence.

Dans un contexte où le code est abondant,
la compétence rare devient la capacité à dire :

cette solution est correcte, mais pas appropriée ici.

III. Une accélération qui rend les erreurs plus rapides  

L’un des effets les plus visibles de l’IA est l’accélération globale du développement :

• plus de code produit,
• plus de fonctionnalités livrées,
• plus de variantes explorées.

Mais cette accélération s’applique aussi :

• aux mauvaises abstractions,
• aux mauvais découpages,
• aux décisions prises sans recul.

Un système mal structuré devient problématique plus vite, pas moins.

IV. Lire et modifier du code généré par l’IA reste un travail humain  

Lorsque du code est généré par une IA, il n’est pas fondamentalement différent :

• du code écrit par un collègue,
• ou du code legacy sans auteur identifiable.

Dans tous les cas, le développeur doit :

• comprendre l’intention,
• identifier les responsabilités,
• évaluer la qualité du découpage,
• décider comment le faire évoluer.

L’IA ne supprime pas ce travail.
Elle déplace simplement le moment où il devient inévitable.

V. Le danger du code “raisonnable mais fragile”  

Un phénomène fréquent avec l’IA est la production de code :

• lisible,
• cohérent localement,
• conforme aux conventions.

Mais ce code peut rester fragile sur le long terme :

• abstractions trop générales,
• dépendances inutiles,
• logique dispersée.

Ce n’est pas du mauvais code.
C’est du code difficile à faire évoluer sans compréhension profonde.

Comme le rappelle souvent Kent Bec, la lisibilité humaine et la capacité à changer le code sont des critères plus importants que la simple correction fonctionnelle.

VI. Prompter n’est pas décider  

Écrire un prompt revient à formuler une intention.
Mais une intention n’est pas une décision de conception complète.

Même avec des contraintes explicites :

• des tests,
• des règles de style,
• des guidelines,

l’IA doit encore :

• interpréter,
• choisir,
• arbitrer.

Pour obtenir des résultats cohérents, le développeur doit donc apprendre à écrire des prompts clairs, structurés et contextualisés. Cela implique de savoir :

• expliciter le contexte fonctionnel,
• décrire les contraintes importantes,
• formuler des objectifs précis plutôt que vagues.

Mais cette compétence ne remplace pas la décision de conception. Elle en dépend.

Si le développeur n’est pas capable d’expliquer les choix faits par l’IA après coup,
alors le système devient dépendant de l’outil plutôt que réellement maîtrisé.

VII. L’IA comme amplificateur de maturité  

Dans la pratique, l’IA agit rarement comme un égalisateur.
Elle agit comme un amplificateur :

• un développeur expérimenté obtient plus vite une solution pertinente,
• un développeur moins expérimenté obtient plus vite une solution qu’il ne sait pas encore juger.

Ce constat rejoint des idées anciennes du craft logiciel :
les outils ne remplacent pas l’expérience, ils la rendent plus visible.

VIII. Pourquoi les fondamentaux deviennent encore plus importants  

Avec l’IA, certaines compétences deviennent plus importantes, pas moins :

• savoir découper un problème,
• reconnaître une abstraction inutile,
• identifier un couplage dangereux,
• simplifier avant d’ajouter.

Ces compétences ne s’acquièrent pas par le prompting,
mais par l’expérience répétée de l’écriture, de la lecture et de la modification de code.

IX. Apprendre à coder reste un passage obligé  

Même dans un contexte fortement assisté par l’IA, apprendre à coder reste essentiel :

• pour développer une intuition technique,
• pour reconnaître une mauvaise solution,
• pour comprendre les conséquences d’un choix.

X. Conclusion  

L’IA transforme profondément la production de code.
Mais elle ne transforme pas la nature du travail logiciel.

Le cœur du métier reste la prise de décision sous contrainte.

Le code est plus rapide à produire.
La responsabilité, elle, reste humaine.

Liens utiles  

• The Skill That Separates Good Developers from GREAT Ones Une réflexion de Emily Bach sur le lien entre code, design, modèle mental et usage des assistants IA.

• Articles sur la lisibilité et la maintenabilité du code
  En particulier ses écrits sur la compréhension humaine du code et le refactoring comme activité centrale.

• Tidy First? Un livre court de Kent Bec sur l’importance de petites décisions structurelles avant d’ajouter du comportement, très pertinent à l’ère de l’IA.

• Publications sur l’IA et le craft logiciel Retours d’expérience concrets sur l’usage des outils d’IA en développement, avec un fort accent sur le jugement et la qualité.