Dans Slam Dunk, Sakuragi ne devient pas utile en apprenant à tout faire. Il devient redoutable en devenant excellent sur une chose que les autres négligent : le rebond. Il ne marque pas, il ne dribble pas, il attrape des ballons — et son équipe gagne des matchs grâce à ça.
C'est la question que pose l'IA à notre métier. Pas « vais-je être remplacé ? », mais « qu'est-ce que je fais que la machine ne fait pas, et est-ce que je le fais bien ? »
J'utilise ces outils quotidiennement, sur des projets réels et en production. Voici ce que j'observe, sans enthousiasme ni panique.
Ce que ça fait très bien
Le code de plomberie. Un client HTTP typé à partir d'une spec, un formulaire avec validation, une migration de schéma, la conversion d'un format vers un autre. Ce travail était ennuyeux et prenait du temps. Il prend maintenant quelques minutes.
Se souvenir de la syntaxe. L'ordre des arguments d'une fonction obscure, l'incantation exacte pour un pipeline. C'était de la consultation de documentation. C'est devenu une question.
Le premier jet. Partir d'un fichier vide coûte cher psychologiquement. Partir d'un brouillon imparfait à corriger, beaucoup moins.
Expliquer du code inconnu. Sur une reprise de projet, demander « que fait cette fonction » accélère réellement la phase de découverte.
Sur ces quatre points, le gain est net. Le nier serait malhonnête.
Ce que ça ne fait pas
Savoir quel code écrire. Sur la plateforme de soins à domicile à laquelle je contribue, une visite annulée moins de deux heures avant reste facturée à 50 % — pour ce client-là, selon ce contrat-là. Cette règle n'est écrite nulle part. Elle vit dans la tête d'une personne qu'il faut aller écouter. Aucun modèle ne la devinera.
Arbitrer. Faut-il rendre ce paramètre configurable par client ? Oui pour vendre, non pour maintenir. La réponse dépend de la stratégie commerciale, pas du code. Un outil te donnera un avis argumenté dans les deux sens ; il ne portera pas la décision.
Dire non. « Cette fonctionnalité va créer une dette qu'on paiera pendant deux ans, et le besoin réel derrière est différent. » Cette phrase demande de comprendre le besoin et d'accepter le désaccord.
Assumer. Quand la production tombe à 23 h, quelqu'un doit décider de revenir en arrière ou de corriger à chaud. C'est une responsabilité, pas une compétence technique.
Douter au bon endroit. C'est le point le plus important, et le plus difficile à formuler.
Le vrai risque : la confiance mal placée
Le danger n'est pas que ces outils écrivent du mauvais code. C'est qu'ils écrivent du code plausible.
Un débutant produit du code visiblement faux. Un modèle produit du code qui a l'air correct, respecte les conventions, porte de bons noms — et contient une erreur subtile. Il te propose une gestion de paiement sans idempotence : ça marche parfaitement en test, et ça crée des doublons en production le jour où un utilisateur tape deux fois.
Pour repérer ça, il faut déjà savoir. Ce qui crée un paradoxe : l'outil est le plus utile à ceux qui en ont le moins besoin, et le plus dangereux pour ceux qui l'utiliseraient le plus.
Ma discipline personnelle :
- Je ne fusionne jamais du code que je ne peux pas expliquer ligne à ligne. Si je ne sais pas pourquoi une ligne est là, elle sort.
- Sur les zones sensibles — paiement, authentification, isolation de données — je pars de la documentation officielle, pas d'une suggestion. Je peux m'en servir pour relire, pas pour écrire.
- Je teste les cas d'échec en priorité. Le chemin nominal est justement ce que ces outils produisent le mieux ; les cas tordus, non.
Ce qui prend de la valeur
Si écrire du code devient rapide, la rareté se déplace. D'après ce que je constate sur mes propres missions :
Comprendre un métier. Savoir interviewer un utilisateur, repérer le cas particulier qui va tout structurer, traduire une réalité de terrain en modèle. C'est ce qui distingue un logiciel utilisé d'un logiciel livré.
Juger. Face à trois solutions qui fonctionnent, choisir celle qui coûtera le moins cher dans deux ans. Ça demande d'avoir vécu ces deux ans.
Exploiter. Savoir pourquoi un disque se remplit, pourquoi PostgREST ne joint plus Postgres, pourquoi ton site affiche une page vide sans lever d'erreur. J'ai passé une matinée là-dessus, et aucun assistant n'aurait trouvé à ma place — parce qu'il fallait d'abord savoir quelle question poser.
Communiquer. Expliquer un arbitrage technique à quelqu'un qui n'est pas technique. Écrire un message qui évite trois allers-retours. Cette compétence, largement méprisée, devient centrale à mesure que le reste s'automatise.
Relire. La revue de code passe de contrôle qualité à compétence principale. Il y a beaucoup plus de code à relire, produit plus vite, par des gens qui l'ont moins réfléchi.
Le problème de fond pour la profession
Ce qui m'inquiète n'est pas le remplacement. C'est l'érosion du chemin d'apprentissage.
On devenait bon en écrivant du code médiocre, en le voyant casser, en le corrigeant. Cette boucle — écrire, souffrir, comprendre — est le mécanisme d'apprentissage. Si un débutant obtient immédiatement du code correct sans jamais passer par la souffrance, où acquiert-il le jugement ?
Les tâches simples, celles qu'on confiait aux juniors, sont précisément celles que l'automatisation absorbe le mieux. On risque de créer une génération à qui l'on demande d'avoir du jugement sans lui avoir donné les moyens de le construire.
Je n'ai pas de solution générale. Ce que je fais, à mon échelle :
- Écrire d'abord, demander ensuite. Sur un sujet que je veux apprendre, je produis ma version avant de la comparer. La comparaison enseigne ; la copie non.
- Faire le difficile à la main. Ce qui me coûte est exactement ce qui me fait progresser. Déléguer précisément ça, c'est acheter du temps contre de la compétence.
- Transmettre. J'ai animé un groupe de formation React Native où l'on faisait de la revue de code entre nous. Expliquer son code à quelqu'un reste le meilleur détecteur de ce qu'on n'a pas compris.
Ce que je dirais à quelqu'un qui débute aujourd'hui
Ne refuse pas ces outils : ce serait travailler avec un handicap volontaire.
Mais choisis délibérément où tu acceptes de ne pas aller vite. Les fondamentaux — comment fonctionne une base de données, ce qu'est une transaction, ce que coûte un appel réseau, pourquoi une requête est lente — ne s'acquièrent que par l'effort. Ce sont eux qui te permettront, plus tard, de repérer le code plausible mais faux.
Et cultive ce que la machine ne touche pas : la compréhension du métier, le jugement, la responsabilité. C'est le rebond de Sakuragi. Ce n'est pas spectaculaire, ça ne fait pas de belles démonstrations, et c'est ce qui fait gagner les matchs.
Si tu veux un avis extérieur sur un produit, une architecture ou une reprise de projet, écris-moi — le premier échange est gratuit.