99% de mon code est généré par IA. Et je ne me suis jamais senti aussi utile.

99% du code que j'envoie en production est écrit par un agent IA.

Les 1% restants ?

Des corrections, des ajustements, des simplifications. Et je suis convaincu que ce 1% va disparaître très vite, remplacé par de l'échange en langage naturel avec l'agent.

Pourtant, je n'ai jamais été aussi utile, aussi performant, aussi impactant dans mon métier de développeur.

Paradoxe ? Pas du tout. Je me suis juste rebasé.

Je m'appelle Thibault. Je navigue dans les eaux du Web depuis le tournant des années 2010. Après quelques années de dev front-end puis un passage en engineering management, en 2023 j'ai retroussé les manches pour rejoindre les fondateurs de Catalog.

On était 4 : un CTO, un CEO, un autre dev et moi, à poser les premières lignes de code de ce qui devait être le "Shopify B2B".

Trois ans plus tard, on est une vingtaine, dont une grosse dizaine à la tech. Catalog a depuis pivoté vers un catalogue d'agents IA pour les plateaux commerciaux B2B.

Et moi, j'ai toujours les manches retroussées pour shipper des features.

Sauf que je n'écris quasiment plus une ligne de code.

Suis-je repassé manager ?

Oui et non. Disons que je manage mes agents. Une horde de Claude Code, Claudio pour les intimes. C'est l'agent que j'ai choisi après avoir testé quasiment tous les outils du marché : Copilot, Cursor, Kiro, Codex, Antigravity.

Claude Code est celui avec lequel j'ai développé le meilleur flow et surtout le plus de confiance. Et cette notion de confiance, elle est essentielle. J'y reviendrai.

Concrètement, ma journée type ressemble à ça : je récupère un ticket sur Linear, j'analyse les specs. Je me projette. Quels repos vont être impactés ? Comment cette feature s'insère dans l'existant ? Quels patterns utilise-t-on déjà ? Quels sont les risques de régressions, les edge cases ? Bref, le travail de fond que tout dev consciencieux fait avant d'attaquer un ticket.

Rien de révolutionnaire jusque là.

Ce qui change, c’est la suite.

Au lieu d'ouvrir mon éditeur, j'ouvre mon terminal et je prompte. Je donne à Claudio le contexte, le fruit de ma réflexion, je lui recommande d'utiliser des skills spécifiques.

Et attention, Claudio ne fonce pas tête baissée dans le code. On échange. Il challenge mes réflexions, je challenge ses outputs.

Puis il propose un plan d'implémentation en markdown : ce qu'il va faire, dans quel ordre. Je relis, je corrige si besoin, je valide. Et là seulement, Claude code. Une fois terminé, je relis son travail comme je relis les pull requests de mes collègues.

Je suis toujours développeur. Je ne suis plus un codeur

Le débat dominant est binaire et stérile : "l'IA remplace les devs" contre "l'IA est un gadget qui va s'essouffler."

Les deux ont tort.

Quand la photographie numérique est arrivée, les photographes argentiques ont eu le même débat. Certains ont dit "c'est la fin du métier", d'autres ont dit "ça ne vaudra jamais la pellicule." En réalité, le métier s'est transformé. Les photographes n'ont pas disparu. Ils ont arrêté de passer des heures en chambre noire pour se concentrer sur le cadrage, la lumière, la direction artistique, le post-traitement numérique. Leur valeur s'est déplacée.

C'est exactement ce qui nous arrive.

Notre métier ne s'éteint pas, il mute. Pas vers le haut (devenir CEO, CPO ou CTO, même si ça reste une voie possible). Pas vers le bas (opérateur de prompt qui exécute sans comprendre). Il mute vers le large.

Ce que j'appelle le dev 360, c'est une posture.

Un dev qui a une vision globale : produit, qualité, sécurité, business, et qui ne se définit plus par les lignes de code qu'il écrit mais par l'impact qu'il produit.

Concrètement, trois choses bougent.

L'une est radicalement nouvelle.

Les deux autres existaient déjà, mais leur poids change.

C'est la compétence qui n'existait pas il y a deux ans.

Dans ma journée, je fais tourner plusieurs instances de Claude en parallèle. L'une code une feature. L'autre génère une documentation. Une troisième m'explique un repo que je ne connais pas encore. Une autre réfléchit à une feature à intégrer…

Ça demande une gymnastique nouvelle. Un context switching qui, historiquement, a toujours été l'ennemi du dev. Moi le premier, j'avais besoin d'un focus total sur une seule tâche. Je fuyais tout ce qui pouvait me détourner de mon travail.

Aujourd'hui, les agents me permettent d'être efficacement multi-tâche.

C'est un vrai changement de paradigme.

Tel le pilote de ligne dans son cockpit qui orchestre, vérifie, s'assure que l'appareil arrive à bonne destination. Et qui reprend la main quand ça déraille. Personne ne monte dans un avion sans pilote. Même si l'avion sait voler tout seul.

Pour être efficace, il faut un bon setup, des workflows rodés et une méthode que l'on affine en continu. J'y consacrerai des numéros entiers dans Le Rebase.

Comprendre le produit, les enjeux business, le contexte métier, les bons devs l'ont toujours fait. C'est ce qui faisait la différence entre un dev correct et un dev excellent.

Ce qui change, c'est que ça devient un prérequis.

Et voici ma conviction, peut-être la plus clivante de ce premier numéro : les organisations vont changer.

Le modèle où un PM rédige un ticket avec douze acceptance criteria millimétrés, où le dev n'a qu'à dérouler le plan…

Ce modèle est en sursis. De plus en plus, le dev va recevoir un brief. Un objectif. Un problème à résoudre. Et c'est à lui d'en déduire les specs, les critères d'acceptance, la stratégie technique.

Ce modèle est déjà une réalité dans les startups. Je suis convaincu qu'il va s'étendre, plus ou moins rapidement selon les contextes, à l'ensemble des organisations IT.

Conséquence directe : le dev qui se planquait derrière "c'était pas dans les specs" perd sa dernière ligne de défense. Cette posture, qui était déjà un signe de faiblesse, devient un vrai risque.

Pas parce que ces devs sont mauvais, mais parce que le métier ne leur laissera plus cet espace.

Un bon prompt naît d'une bonne compréhension du besoin. Si tu ne comprends pas pourquoi tu construis quelque chose, ton agent produira du code techniquement correct mais fonctionnellement à côté de la plaque. La compréhension produit n'est plus un bonus, c'est le socle de tout le reste.

Ici, rien de nouveau dans le principe.

Pas de prod, pas de business.

En tant que devs, on a toujours eu un devoir de protection de la production.

Ce qui change, c'est l'intensité, et la nature du dispositif qu'on met derrière.

Le code que tu déploies, tu ne l'as pas écrit toi-même. Il a été produit par une IA qui va vite et qui produit beaucoup. Aucun transfert de responsabilité pour autant.

Je me vois mal dire à mon CTO : "C'est pas moi qui ai planté la prod, c'est Claudio."

Quand tu écrivais le code toi-même, tu avais une connaissance intime de ce que tu produisais. Quand c'est un agent qui l'écrit, cette intimité disparaît. Tu dois la compenser par de la méthode.

Concrètement, chez Catalog : une couverture de tests qu'on n'aurait jamais atteinte à la main, des revues de PR blindées par CodeRabbit en première passe, des skills Claude Code dédiés à la review en seconde passe, et la validation humaine en bout de chaîne.

C'est ce dispositif qui ramène à la confiance dont je te parlais en intro.

Cette confiance, je ne l'ai pas accordée à l’IA en un jour. Elle s'est construite par paliers.

D'abord l'autocomplétion.

Puis le chat, où je lui demandais un petit bout de code que je recopiais à la main.

Ensuite, je l'ai laissé éditer mon code directement, petit bloc par petit bloc.

Sont arrivés les modes plan, où je validais et discutais chaque étape.

Enfin le mode auto : je laisse l'agent dérouler tout le plan d'un trait, je relis à la fin.

Aujourd'hui, l'agent pousse directement la pull request sur GitHub. Le filet de sécurité (tests, CodeRabbit, review humaine sur la PR) prend le relais.

Cette progression a un nom.

Saranya Gunasekaran l'a théorisée en décembre 2025 sur UXmatters dans "Designing for Autonomy" : la relation humain-agent ne se joue pas en bascule binaire (tout manuel ou tout auto), mais sur un curseur d'autonomie qu'on déplace au fil de la confiance gagnée.

Et qu'on rétracte direct quand un incident la fait reculer.

La responsabilité n'a pas changé. L'exigence, si.

Cette tendance à l'élargissement du périmètre du dev pose une question légitime : si le dev devient accessible aux non-techs, est-ce que n'importe qui peut coder ?

La réponse est oui, techniquement. Mais attention au mythe.

La narrative dominante sur LinkedIn et Twitter : "j'ai construit mon SaaS en 48h sans aucune notion de code", me rappelle le tournant des années 2010 et le mythe du blogueur millionnaire. "Lancez votre blog et devenez riche."

Oui, il y a eu quelques success stories.

Pour combien d'échecs silencieux ?

Je le vis quotidiennement chez Catalog, dans un écosystème très tech et très senior : le vibe coding pur, sans process, sans relecture de code, sans choix architecturaux éclairés, n'est pas prod-ready. Sans monitoring, sans politique de sécurité forte, sans maîtrise des coûts, c'est le crash assuré !

On verra dans quelques mois ce que sont devenues ces apps "codées en une nuit."

Mais attention, je ne rejette pas le vibe coding en bloc.

Au contraire !

Mon CTO chez Catalog n'est peut-être pas le meilleur codeur de l'équipe.

Mais sa vision technique, sa connaissance aiguë du produit et des enjeux business en font l'un des shippers les plus prolifiques de la boîte.

Parce qu'il sait ce qu'il fait.

Parce qu'il a des flows précis qu'il optimise en permanence.

Et il a su insuffler cette culture dans toute l'équipe.

On lui consacrera d'ailleurs un numéro du Rebase (s’il m’y autorise 😎).

Le message n'est pas "le vibe coding ne marche pas." C'est : le vibe coding sans compétences est un mirage.

C'est dans cette idée que je veux t'embarquer. Notre métier s'ouvre sur une nouvelle ère. On peut s'en réjouir. On peut s'en inquiéter. Mais on ne peut pas l'ignorer.

Moi, je suis enthousiaste.

Et je veux t'aider à te rebase.

À embrasser ce que j'appelle le DAA : le Développement Assisté par Agent.

L'agent produit le code. Le dev le brief, le pilote, le contrôle. C'est une pratique différente du simple autocomplete à la Copilot : ici, l'agent est autonome, et le dev est le garant de la qualité.

Chaque mardi dans Le Rebase, tu trouveras :

Le dev ne meurt pas, il se rebase. Le code devient commodité. Ce qui compte maintenant : comprendre le produit, piloter les agents, garantir ce qui tourne en prod. Pas un framework. Une posture. Si tu veux suivre cette transformation de l'intérieur, tu es au bon endroit.

Si cette vision te parle, transfère ce mail à un dev que ça pourrait intéresser. C'est le meilleur moyen de faire grandir Le Rebase.