Quand l’IA commence à écrire du code

Pendant longtemps, coder voulait dire écrire soi-même chaque ligne.

Chercher la bonne syntaxe. Lire la documentation. Tester. Se tromper. Recommencer. Comprendre pourquoi ce petit point-virgule oublié avait décidé de ruiner la matinée.

Puis les assistants IA sont arrivés.

D’abord comme des compléteurs intelligents.

Une ligne suggérée. Une fonction terminée. Un import deviné. Une docstring proposée.

Ensuite, ils sont devenus capables de générer des blocs entiers, de corriger des erreurs, d’expliquer du code, de proposer des tests, de refactoriser une fonction, parfois même de prendre en charge une petite tâche complète.

Aujourd’hui, pour beaucoup de développeurs, la question n’est plus :

Est-ce que l’IA peut aider à coder ?

La question devient :

Comment coder avec l’IA sans perdre la maîtrise de ce que l’on construit ?

Car l’IA ne change pas seulement la vitesse d’écriture.

Elle change le geste même du développement.

Le développeur n’écrit pas forcément moins : il travaille autrement

Dire que l’IA “code à notre place” est trop simple.

Parfois, oui, elle écrit beaucoup.

Mais cela ne veut pas dire que le développeur disparaît.

Son rôle se déplace.

Avant, une grande partie du travail visible consistait à écrire le code directement.

Avec l’IA, une part croissante du travail devient :

  • définir le besoin ;
  • cadrer la demande ;
  • donner le bon contexte ;
  • limiter le périmètre ;
  • relire la proposition ;
  • détecter les effets de bord ;
  • lancer les tests ;
  • analyser les erreurs ;
  • corriger ;
  • valider ;
  • décider si le résultat est acceptable.

Le geste devient moins linéaire.

On ne fait plus simplement :

penser → écrire → tester.

On fait plutôt :

cadrer → générer → relire → tester → corriger → valider.

Ce n’est pas forcément plus simple.

C’est différent.

Et parfois, c’est plus exigeant qu’on ne l’imagine.

Parce qu’une IA peut produire vite.

Mais produire vite n’est pas comprendre juste.

Le code généré n’est pas du code validé

C’est la règle la plus importante.

Le code généré n’est pas du code validé.

Une IA peut écrire une fonction propre. Elle peut corriger une erreur visible. Elle peut proposer un patch cohérent. Elle peut produire un test qui semble raisonnable. Elle peut même expliquer son travail avec beaucoup d’assurance.

Mais cela ne prouve pas que le code est bon.

Un code généré peut :

  • fonctionner sur un exemple simple ;
  • casser un cas limite ;
  • modifier un comportement voisin ;
  • ignorer une contrainte métier ;
  • ajouter une dépendance inutile ;
  • contourner le problème réel ;
  • produire une solution trop large ;
  • supprimer une sécurité ;
  • réussir les tests existants mais échouer en usage réel ;
  • donner l’impression d’être propre alors qu’il déplace la dette technique.

C’est particulièrement vrai sur les projets déjà existants.

Dans un petit script isolé, l’IA peut être spectaculaire.

Dans une application réelle, avec historique, architecture, modules, données, contraintes, interface, tests, packaging et production, le risque change de nature.

Le code n’est pas juste du texte.

C’est un morceau vivant dans un système.

Et un système n’aime pas toujours qu’on lui greffe une réponse brillante trouvée en trente secondes.

Le vrai travail : donner le bon cadre

Avec l’IA de code, le prompt n’est pas une formule magique.

C’est une spécification.

Plus la demande est vague, plus l’IA improvise.

Et une IA qui improvise dans un codebase peut vite devenir un stagiaire surcaféiné avec accès au bouton “modifier tous les fichiers”.

Le bon cadre doit dire :

  • quel est le problème observé ;
  • où il se produit ;
  • ce qui doit être corrigé ;
  • ce qui ne doit pas être touché ;
  • quels fichiers sont concernés ;
  • quels tests doivent passer ;
  • quel comportement attendu doit être vérifié ;
  • quel type de rapport est demandé ;
  • quelles preuves sont nécessaires.

La phrase :

Corrige ce bug.

est beaucoup trop vague.

Une meilleure demande ressemble plutôt à :

Corrige uniquement le problème observé dans ce module. Ne modifie pas le comportement des autres modules. Ne fais pas de refonte. Ajoute ou adapte les tests ciblés si nécessaire. Donne la liste des fichiers modifiés, la cause identifiée, la correction appliquée et les commandes lancées.

C’est moins glamour.

Mais beaucoup plus utile.

L’IA code mieux quand on lui enlève les mauvaises libertés.

L’IA adore élargir le périmètre

L’un des grands pièges des assistants IA est leur tendance à “améliorer” ce qu’on ne leur a pas demandé.

On signale un problème d’affichage.

Elle propose une refonte. On demande une correction ciblée.

Elle renomme des fonctions. On veut un bugfix.

Elle restructure un composant. On demande une validation.

Elle ajoute une couche d’abstraction avec un nom très sérieux, parce que visiblement le monde manquait d’un ManagerServiceCoordinator.

Parfois, l’amélioration est pertinente.

Mais souvent, elle augmente le risque.

Dans un projet réel, tout changement a un coût :

  • coût de relecture ;
  • coût de test ;
  • coût de compréhension ;
  • coût de maintenance ;
  • coût de régression possible ;
  • coût mental pour le développeur.

Coder avec l’IA demande donc une discipline simple :

Corriger le défaut précis observé, sans toucher au reste.

Pas par peur d’améliorer.

Mais parce qu’un bon changement doit être proportionné au problème.

Un patch propre n’est pas celui qui change le plus de choses.

C’est celui qui résout le problème avec le moins de dégâts possibles.

Les modèles IA ne remplacent pas l’architecture

Les modèles de code progressent vite.

Ils peuvent lire des fichiers, proposer des modifications, comprendre des erreurs, écrire des tests, générer des composants, créer des scripts.

Mais ils ne remplacent pas une vision d’architecture.

Une architecture, ce n’est pas seulement “où mettre le fichier”.

C’est la compréhension des responsabilités.

Qui décide ? Qui affiche ? Qui stocke ? Qui valide ? Qui appelle qui ? Quelle partie doit rester stable ? Quelle partie peut évoluer ? Quelle dépendance est acceptable ? Quelle dette technique est dangereuse ?

Une IA peut aider à formuler cette architecture.

Elle peut la documenter.

Elle peut en proposer une version plus claire.

Mais si l’humain ne sait pas ce qu’il veut protéger, l’IA peut très vite produire une solution séduisante et mal placée.

Le code marche parfois.

Puis trois semaines plus tard, on découvre qu’un module dépend d’un autre qui ne devrait jamais le connaître.

Et là, évidemment, tout le monde regarde ses chaussures.

Coder avec l’IA demande plus de tests, pas moins

Un autre piège consiste à croire que l’IA réduit le besoin de tests.

C’est l’inverse.

Plus le code est généré vite, plus les tests deviennent importants.

Pourquoi ?

Parce que l’IA accélère la production de possibilités.

Elle peut générer dix solutions avant que l’on ait fini de comprendre la première.

Sans tests, on juge au feeling.

Avec tests, on juge sur comportement.

Les tests ne garantissent pas tout.

Mais ils obligent à formuler une attente.

Ils transforment une impression en vérification.

Un bon workflow IA doit donc inclure :

  • tests unitaires ;
  • tests ciblés sur le bug ;
  • vérification du comportement attendu ;
  • contrôles de non-régression ;
  • lecture des logs ;
  • test manuel si l’interface est concernée ;
  • validation sur artefact final quand le sujet touche au packaging ou à la production.

L’IA peut écrire des tests.

Mais il faut vérifier que ces tests testent vraiment quelque chose.

Un test généré peut être joli, vert, et inutile.

Le vert ne signifie pas toujours “validé”.

Parfois, il signifie seulement :

Le test confirme exactement ce que le code fait déjà, y compris quand ce comportement est mauvais.

Petit chef-d’œuvre de l’absurde moderne.

Le rapport de l’IA doit devenir une preuve, pas une histoire

Quand une IA termine une tâche de code, elle adore expliquer.

Elle dit ce qu’elle a corrigé. Elle dit que tout est bon. Elle dit que les tests passent. Elle dit que le problème est résolu.

Très bien.

Mais dans un projet sérieux, un rapport ne suffit pas.

Il faut des preuves.

Un bon rapport doit contenir :

  • les fichiers modifiés ;
  • la cause identifiée ;
  • la correction appliquée ;
  • les tests lancés ;
  • les résultats exacts ;
  • les limites restantes ;
  • ce qui n’a pas été testé ;
  • les éventuels risques.

Sans cela, on obtient un récit.

Pas une validation.

Et un récit peut être faux.

Même quand il est très bien écrit.

Avec l’IA, il faut apprendre à demander des preuves concrètes :

Quelle commande as-tu lancée ? Quel test est passé ? Quel fichier a changé ? Quel comportement a été vérifié ? Qu’est-ce qui reste non testé ?

Ce n’est pas de la méfiance gratuite.

C’est de l’hygiène de projet.

Les vrais gains existent

Il ne faut pas tomber dans l’excès inverse.

L’IA peut vraiment aider à développer.

Elle peut faire gagner du temps sur :

  • les fonctions répétitives ;
  • les scripts utilitaires ;
  • la génération de tests de base ;
  • la lecture d’erreurs ;
  • la documentation ;
  • les docstrings ;
  • les migrations simples ;
  • les refactorings encadrés ;
  • la compréhension d’un fichier ancien ;
  • la comparaison de solutions ;
  • la traduction d’une idée en structure de code.

Elle peut aussi aider à débloquer mentalement.

Quand on est fatigué, l’IA peut proposer une première piste.

Quand on se perd dans un bug, elle peut reformuler le problème.

Quand on n’arrive plus à voir une architecture, elle peut aider à la cartographier.

Dans ces cas-là, elle devient un vrai partenaire.

Pas parce qu’elle sait tout.

Mais parce qu’elle permet de faire apparaître quelque chose à examiner.

Et parfois, avoir quelque chose à critiquer est déjà beaucoup mieux que rester face à un mur.

Les faux gains existent aussi

Mais il y a aussi des gains qui n’en sont pas vraiment.

L’IA peut produire vite un patch qui demande ensuite une heure de relecture.

Elle peut générer un test qui passe mais ne protège rien.

Elle peut corriger un symptôme au lieu de corriger la cause.

Elle peut proposer une solution plus complexe que le problème.

Elle peut créer une dépendance inutile.

Elle peut transformer une correction de cinq lignes en modification de six fichiers.

Elle peut donner l’impression qu’on avance alors qu’on produit surtout de la vérification.

Le coût caché du code IA est souvent là :

ce n’est pas le temps de génération, c’est le temps de reprise.

Il faut donc mesurer le gain réel.

Pas seulement :

L’IA a produit quelque chose en trente secondes.

Mais :

Est-ce que cela m’a réellement rapproché d’un résultat fiable ?

Si la réponse est non, l’IA n’a pas accéléré.

Elle a déplacé le travail.

Le développeur devient aussi éditeur

Coder avec l’IA ressemble de plus en plus à un travail d’édition.

Pas seulement écrire.

Mais choisir.

Couper. Refuser. Corriger. Assembler. Réordonner. Simplifier. Demander une autre version. Garder une ligne. Jeter le reste.

Le développeur devient moins seulement “celui qui tape le code”.

Il devient celui qui dirige la production de code.

Cette position est puissante.

Mais elle demande une vraie exigence.

Un mauvais éditeur accepte tout.

Un bon éditeur sait dire :

Non. Trop large. Trop risqué. Hors sujet. Pas assez testé. Trop abstrait. Reviens au problème réel.

Coder avec l’IA, ce n’est donc pas lâcher le clavier.

C’est parfois tenir plus fermement la direction.

Le danger pour les débutants

L’IA peut être merveilleuse pour apprendre.

Elle peut expliquer une erreur, donner des exemples, reformuler une notion, comparer deux approches, proposer des exercices.

Mais elle peut aussi être dangereuse pour les débutants.

Pourquoi ?

Parce qu’un débutant ne sait pas encore toujours reconnaître une mauvaise réponse.

Il peut copier du code sans comprendre. Il peut accepter une architecture fragile. Il peut croire qu’un test vert suffit. Il peut accumuler des solutions qu’il ne saura pas maintenir. Il peut progresser en apparence, mais perdre la compréhension profonde.

L’IA ne doit donc pas devenir une béquille permanente.

Pour apprendre à coder avec elle, il faut parfois lui demander :

  • explique-moi pourquoi ;
  • donne-moi une version simple ;
  • montre-moi l’erreur ;
  • propose un exercice ;
  • compare deux solutions ;
  • indique les risques ;
  • ne me donne pas directement la réponse ;
  • guide-moi étape par étape.

L’IA peut être un professeur.

Mais il faut lui demander d’enseigner, pas seulement de résoudre.

Le danger pour les développeurs expérimentés

Les développeurs expérimentés ne sont pas épargnés.

Leur piège est différent.

Ils savent détecter beaucoup d’erreurs.

Mais ils peuvent être tentés d’aller trop vite.

Ils peuvent confier trop de contexte. Accepter une correction plausible. Se laisser séduire par une architecture bien nommée. Oublier un cas limite. Sous-estimer le coût de relecture. Multiplier les prompts jusqu’à perdre le fil.

L’IA peut donner une impression de super-pouvoir.

Et parfois, c’est vrai.

Mais un super-pouvoir sans protocole finit souvent en dette technique avec une cape.

Le développeur expérimenté doit donc utiliser l’IA comme un multiplicateur.

Pas comme une excuse pour relâcher la méthode.

Plus le modèle est puissant, plus le cadre doit être clair.

Plus la tâche est critique, plus la preuve doit être solide.

Plus le code touche à la production, moins il faut croire sur parole.

Un bon workflow pour coder avec l’IA

Un workflow simple peut éviter beaucoup de dégâts.

Décrire le problème réel

Avant de demander une correction, écrire le problème observé.

Pas seulement l’erreur.

Le comportement attendu. Le comportement actuel. Le contexte. Le module concerné. Les limites.

Réduire le périmètre

Dire explicitement ce qui ne doit pas être modifié.

C’est souvent aussi important que dire quoi corriger.

Demander une analyse avant le patch

Ne pas commencer par :

Corrige.

Commencer par :

Analyse la cause probable et propose un plan court avant modification.

Cela évite parfois les patchs impulsifs.

Corriger ciblé

Une fois la cause claire, demander une correction limitée.

Pas de refonte.

Pas d’amélioration globale.

Pas de nettoyage hors sujet.

Tester

Lancer les tests utiles.

Pas forcément toute la cathédrale à chaque micro-correction.

Mais assez pour prouver que le comportement attendu tient.

Relire

Regarder le code modifié.

Même si les tests passent.

Surtout si les tests passent trop facilement.

Valider

Pour une interface, tester visuellement.

Pour un build, tester l’artefact final.

Pour une production, vérifier en conditions réelles.

Choisir le bon modèle pour coder

Tous les modèles ne méritent pas le même usage.

Un modèle premium peut être justifié pour :

  • architecture complexe ;
  • bug critique ;
  • refactoring profond ;
  • analyse multi-fichiers ;
  • sécurité ;
  • performance ;
  • validation de release ;
  • problème bloquant en production.

Un modèle plus léger peut suffire pour :

  • reformulation de commentaire ;
  • docstring ;
  • petit script ;
  • génération d’exemples ;
  • explication d’erreur simple ;
  • nettoyage local ;
  • premier brouillon de test.

Le bon modèle n’est pas toujours le plus cher.

C’est celui qui correspond au risque.

Utiliser un modèle très coûteux pour une tâche simple peut vider un budget sans améliorer le résultat.

Utiliser un modèle trop faible pour une tâche critique peut coûter encore plus cher en erreurs.

La bonne question est donc :

Quel niveau d’intelligence, de contexte et de validation cette tâche mérite-t-elle ?

Pas plus.

Pas moins.

Ce que l’IA ne doit pas décider seule

Certaines décisions doivent rester humaines.

Par exemple :

  • changer une architecture ;
  • ajouter une dépendance ;
  • supprimer un comportement existant ;
  • modifier un système de licence ;
  • toucher à la sécurité ;
  • changer un format de données ;
  • modifier une logique de paiement ;
  • casser une compatibilité ;
  • valider une release ;
  • déclarer un bug résolu.

L’IA peut conseiller.

Mais elle ne doit pas décider seule.

Plus une décision a des conséquences longues, plus elle doit être explicite.

Avec l’IA, le danger n’est pas seulement l’erreur.

C’est l’erreur silencieuse.

La petite modification qui passe dans un patch, paraît raisonnable, et devient un problème trois semaines plus tard.

Le bon développeur ne surveille donc pas seulement ce que l’IA écrit.

Il surveille ce qu’elle suppose.

Garder le plaisir de comprendre

Au milieu de toute cette méthode, il ne faut pas oublier une chose simple : coder, c’est aussi comprendre.

Il y a un plaisir particulier à voir un système s’éclairer.

Un bug qui semblait absurde devient logique. Une architecture floue devient lisible. Une fonction trop longue retrouve sa forme. Un test qui échoue raconte enfin quelque chose. Une idée devient outil.

L’IA peut accélérer ce moment.

Mais elle peut aussi le voler si on lui délègue trop vite la partie la plus intéressante.

Le but n’est pas seulement de produire du code.

Le but est de construire une relation plus claire avec le système.

Une IA utile ne devrait pas nous transformer en opérateurs de prompts.

Elle devrait nous aider à redevenir meilleurs lecteurs, meilleurs architectes, meilleurs testeurs, meilleurs créateurs.

Écrire moins, comprendre plus

Coder avec l’IA ne signifie pas arrêter de coder.

Cela signifie que le code n’est plus toujours écrit de la même manière.

Parfois, on écrit directement. Parfois, on guide. Parfois, on relit. Parfois, on refuse. Parfois, on demande une variante. Parfois, on reprend tout à la main. Parfois, on utilise l’IA pour comprendre, pas pour produire.

Le développeur de demain ne sera pas forcément celui qui tape le plus vite.

Ce sera celui qui sait :

  • formuler un problème ;
  • cadrer un outil ;
  • lire une réponse ;
  • détecter une erreur ;
  • tester une hypothèse ;
  • protéger une architecture ;
  • valider un résultat ;
  • garder la responsabilité.

L’IA peut écrire des lignes.

Mais elle ne doit pas écrire à notre place la compréhension du système.

C’est là que reste le cœur du métier.

Pas dans chaque caractère tapé.

Mais dans la capacité à savoir ce qu’on fait, pourquoi on le fait, et ce qu’on accepte de laisser entrer dans son code.

Au fond, bien coder avec l’IA, ce n’est pas écrire moins pour penser moins.

C’est écrire moins pour comprendre plus.