J’ai passé la matinée à revoir le matériel d’une formation interne. Vingt-six pages denses, pleines de workflows, de commandes, de checklists. À un moment, je me suis arrêté et j’ai regardé par la fenêtre. Je me suis demandé : mais quand est-ce que tout cela est arrivé ?
Il y a un an, on discutait encore d’utiliser Copilot pour l’autocomplétion. Aujourd’hui, on écrit des documents appelés « Constitution » qui gouvernent le comportement d’agents IA générant des fonctionnalités entières. Le saut n’a pas été graduel. C’était comme se réveiller un matin et découvrir que le sol s’était décalé de quelques centimètres pendant la nuit.
Le vibe coding et sa séduction
Il y a un terme qui m’a frappé en préparant le matériel : vibe coding. Décrire vaguement ce qu’on veut et laisser l’IA produire quelque chose. Nous l’avons tous fait, dans les premiers mois. Il y avait quelque chose de presque magique à voir du code apparaître à partir d’une description approximative. Cela marchait ? Parfois oui, souvent non. Mais la sensation de vitesse était grisante.
Le problème, c’est que cette vitesse était une illusion. Le code généré ainsi, sans spécifications précises, sans architecture pensée, accumulait de la dette technique à un rythme impressionnant. Chaque fonctionnalité ajoutée était un pari. Peut-être ça marche aujourd’hui, peut-être tout casse demain quand quelqu’un touche autre chose.
J’ai vu des POC partir comme des fusées et s’écraser en quelques semaines. Pas parce que l’IA s’était trompée, mais parce que personne n’avait pensé à ce qu’on construisait. Nous improvisions avec un outil très puissant sans avoir de partition.
La spécification comme nouvelle forme d’expression
La réponse que nous explorons, et que nous essayons d’enseigner dans ce cours, renverse complètement l’approche. Cela s’appelle le spec-driven development et l’idée de fond est simple, presque banale : on écrit d’abord ce qu’on veut avec une précision maniaque, puis on laisse quelqu’un d’autre (en l’occurrence un agent IA) l’implémenter.
Mais il y a un aspect qui me fascine et m’inquiète à la fois. Écrire des spécifications précises est terriblement difficile. Cela demande de penser à chaque edge case, chaque scénario d’erreur, chaque ambiguïté possible. Cela demande de savoir exactement ce qu’on veut avant de l’avoir vu fonctionner.
D’une certaine façon, c’est l’opposé de la manière dont beaucoup d’entre nous ont appris à programmer. J’ai appris en expérimentant, en essayant, en me trompant, en corrigeant. Un cycle continu d’essais et d’erreurs qui à la fin produisait quelque chose qui marchait. Maintenant, on nous demande de tout penser à l’avance, d’être précis avant d’écrire la moindre ligne de code.
Je ne suis pas sûr que ce soit un changement seulement positif. On perd probablement quelque chose dans l’expérimentation, dans la découverte fortuite de solutions élégantes qui émergent en écrivant. Mais on gagne peut-être autre chose : la possibilité de bâtir des systèmes plus grands et complexes que ce que nous aurions jamais pu faire seuls.
Le paradoxe des compétences
Une chose qui m’a beaucoup fait réfléchir, c’est le paradoxe des compétences qui émerge de cette nouvelle manière de travailler. Dans le document que j’ai préparé, il y a une phrase que j’ai soulignée plusieurs fois :
Cela ne signifie pas que les compétences techniques deviennent obsolètes. Au contraire, il en faut de plus solides.
Cela paraît contre-intuitif. Si l’IA écrit le code, pourquoi devrais-je savoir programmer ? La réponse, c’est qu’il faut savoir programmer mieux qu’avant pour comprendre si ce que l’IA a produit a du sens. Pour valider l’architecture. Pour identifier des problèmes de sécurité. Pour savoir quand quelque chose est un workaround fragile masqué par une solution élégante.
J’ai vu des juniors s’enthousiasmer pour du code généré par l’IA sans se rendre compte qu’il contenait des vulnérabilités graves. Requêtes non paramétrées, validations manquantes, secrets en dur. L’IA avait recopié des patterns peu sûrs vus dans ses données d’entraînement. Il fallait quelqu’un avec de l’expérience pour le repérer.
D’une certaine façon, on devient reviewers à plein temps. Notre travail glisse de la production à la supervision, de l’écriture à la lecture critique. Je ne sais pas si c’est une perte ou un gain. Sans doute les deux.
La Constitution et l’illusion du contrôle
Dans le framework que nous adoptons, il y a un concept central : la Constitution. C’est un document qui définit les principes immuables du projet. Des choses comme « pas de any type permis » ou « couverture minimum 80 % » ou « chaque PR exige une code review humaine ». L’idée est que l’IA doit respecter ces principes dans chaque décision.
Cela fonctionne ? Largement, oui. L’IA suit les règles quand on les lui donne clairement. Mais il y a quelque chose de légèrement ironique. Nous écrivons des constitutions pour des machines. Nous définissons des lois que des algorithmes doivent suivre. C’est une inversion intéressante du rapport entre humains et outils.
Ce que je me demande, sans réponse pour l’instant, c’est jusqu’où ces règles écrites peuvent capter ce que nous voulons vraiment dire. Je peux écrire « pas de workaround ou de hack dans le code », mais comment définir précisément ce qu’est un hack ? Parfois, la distinction entre solution pragmatique et hack est floue, contextuelle, demande du jugement. Ce jugement, pour l’instant, reste humain.
Le temps qui n’est plus là
Une chose qui a changé de manière subtile mais profonde, c’est le rapport au temps. Avant, quand j’estimais combien il fallait pour implémenter une feature, je pensais en heures ou en jours de travail. Maintenant, je pense en termes de combien de temps il me faut pour écrire une spécification suffisamment précise et pour valider l’output.
Paradoxalement, cela prend parfois plus de temps. Écrire une spécification complète, lever toutes les ambiguïtés, définir chaque edge case peut prendre autant que d’écrire le code. Mais le type de travail est différent. Plus mental, plus abstrait. Moins d’heures à fixer un debugger, plus d’heures à penser.
Tous dans l’équipe ne sont pas à l’aise avec ce changement. Certains collègues aimaient justement cette sensation de flow quand le code coule des doigts, quand on est plongé dans le problème et que les solutions émergent presque seules. Cet état mental est plus rare aujourd’hui. Le travail est devenu plus fragmenté, plus fait de reviews et de validations que de création continue.
La sécurité comme obsession nécessaire
Il y a un aspect du code généré par IA qui me met visiblement mal à l’aise : la sécurité. Dans le matériel du cours, j’ai consacré toute une section aux risques spécifiques. Patterns peu sûrs, dépendances vulnérables, requêtes non paramétrées. L’IA n’a pas de malice, mais elle n’a pas non plus de prudence. Elle reproduit ce qu’elle a vu, erreurs incluses.
Ce qui m’inquiète, c’est que beaucoup de ces problèmes ne sautent pas aux yeux. Le code compile, les tests passent, l’application marche. La vulnérabilité est cachée, silencieuse, à attendre que quelqu’un la trouve et l’exploite. Il faut un œil expert pour la repérer. Il faut du temps pour des reviews méticuleuses.
Nous avons ajouté des outils automatiques dans la pipeline : audit des dépendances, scan des secrets, analyse statique. Ils aident, mais ne suffisent pas. À la fin, quelqu’un doit s’asseoir et lire le code ligne par ligne en se demandant : qu’est-ce qui pourrait mal tourner ici ? Et j’ai (re)appris l’importance des tests e2e.
Ce qu’il reste de nous
Je me demande parfois ce qu’il restera de notre métier dans cinq ans. Pas au sens apocalyptique de « les programmeurs seront remplacés », qui me semble une simplification. Mais au sens de ce que nous ferons vraiment, jour après jour.
Probablement, on écrira moins de code et plus de spécifications. On lira plus de code que ce qu’on en écrit. On passera plus de temps à penser à l’architecture, à la sécurité, aux implications de chaque choix. Nous serons moins artisans et plus architectes, moins constructeurs et plus superviseurs.
Je ne sais pas si cela plaira à tout le monde. Beaucoup aimaient écrire du code. Beaucoup aimaient cette sensation de bâtir quelque chose de leurs mains, même si les mains étaient seulement métaphoriques. Peut-être que cette sensation se transformera en autre chose. Ou peut-être qu’on la cherchera ailleurs, dans des projets personnels où personne ne vous oblige à être efficace.
Un métier en transition
Ce que je cherche à transmettre dans le cours, au-delà des commandes et des checklists, c’est la conscience que nous sommes dans un moment de transition. Nous ne savons pas encore où nous allons, mais nous savons que nous ne reviendrons pas en arrière.
Le vibe coding a été une expérience, une phase adolescente dans l’usage de ces outils. Nous essayons maintenant de devenir adultes, de bâtir des processus et des disciplines qui nous permettent d’utiliser cette puissance sans nous faire mal. Un travail en cours, évidemment.
Dans quelques mois, je relirai probablement ce matériel et je le trouverai déjà obsolète. Quelque chose aura encore changé. Les outils seront différents, les workflows auront évolué. C’est le beau et le moche de travailler dans un domaine qui bouge si vite.
Pour l’instant, ce que je peux faire, c’est documenter ce que nous apprenons, le partager avec l’équipe, essayer de bâtir des compétences qui aillent au-delà de l’outil spécifique. La capacité à penser de manière structurée, à écrire des spécifications précises, à valider de manière critique l’output de quelqu’un d’autre : ce sont des aptitudes qui resteront utiles quoi qu’il arrive et qui donneront de la valeur aux personnes.
Ou, du moins, c’est ce que je me répète ces temps-ci.
Ce qu'il faut retenir
Il faut plus de compétence technique, pas moins : il faut savoir programmer mieux qu’avant pour comprendre si ce que l’IA a produit a du sens.
Écrire une Constitution pour des machines ne résout pas le problème du jugement : la distinction entre solution pragmatique et hack reste contextuelle, et ce jugement reste humain.
Le flow du code qui coule des doigts est plus rare : le travail s’est déplacé de la création continue à la review critique.
Questions & réponses
Comment le métier de développeur change-t-il avec les agents IA ?
De celui qui écrit du code à celui qui écrit et valide des spécifications. Avant, le goulot d’étranglement était de produire les lignes ; maintenant, c’est de définir ce qu’il faut produire et de vérifier que cela a été produit correctement. Le code devient un sous-produit de la spécification, et la spécification redevient le cœur du métier — où elle était il y a quarante ans, avant que le boom de la complexité accidentelle ne l’éclipse.
Que veut dire « architecte de spécifications » ?
Quelqu’un capable d’écrire des spécifications exécutables — pas de la documentation narrative, mais des instructions assez précises pour produire un output correct quand elles sont confiées à un agent IA. Cela inclut des tests d’acceptation explicites, des contrats d’interface, des invariants système, des contraintes non fonctionnelles (latence, coûts, sécurité). La compétence n’est pas nouvelle — elle était déjà centrale pour les systèmes formels et TLA+ — mais elle redevient demandée largement.
Celui qui écrit du code est-il en danger d'obsolescence ?
Celui qui n’écrit que du code, oui. Celui qui écrit du code informé par une compréhension profonde du domaine, des trade-offs architecturaux et de la vérification, non — cette compétence reste irréductible. Le risque n’est pas l’IA, c’est l’identité professionnelle bâtie uniquement sur la capacité à taper. La curiosité qui pousse à comprendre pourquoi quelque chose fonctionne est ce qui ne s’automatise pas.
Comment se prépare-t-on à cette transition ?
Trois investissements concrets : (1) apprendre à écrire des spécifications formelles légères — property-based testing, contrats d’interface clairs ; (2) s’habituer à la code review de code généré par IA comme activité primaire, pas secondaire ; (3) développer un jugement de système — quels sont les vrais besoins d’un projet, où l’échec coûte et où non. C’est une métamorphose d’artisan à architecte qui était autrefois réservée à quelques seniors et qui concerne aujourd’hui tout le monde.
L'auteur
