Pourquoi je reconstruis ma carrière AI-native — en public

Pendant huit ans, j'ai construit le genre de logiciels qui font tourner les entreprises sans faire de bruit. Des pipelines ETL chez Deloitte. Des plateformes fintech en Inde. Du SaaS de voyage à Paris. React devant, Node derrière, AWS en dessous. Du CRUD solide, une architecture propre, et de temps en temps une migration héroïque. J'avais l'impression d'un savoir-faire qui prendrait de la valeur indéfiniment.

Puis le sol s'est dérobé. Pas à la manière des gros titres « l'IA va remplacer les développeurs » — d'une manière plus discrète, plus inconfortable. Les parties de mon métier qui étaient autrefois les parties difficiles — brancher des formulaires sur des API, modéliser un domaine en tables, coller des services entre eux — sont désormais celles qu'un modèle fait en une seule passe. Ce que je vendais comme un artisanat est devenu une commodité, et je m'en suis aperçu tard.

Je pouvais faire semblant de rien et tenir encore quelques années. J'ai choisi l'autre option : mon travail consiste maintenant à ré-architecturer une plateforme legacy de climate tech — un logiciel d'Analyse de Cycle de Vie, le genre avec dix ans de schéma accumulé — pour la rendre AI-native. Pas « ajouter un chatbot ». Repenser les endroits où l'architecture suppose qu'un humain remplit un formulaire alors qu'un agent pourrait le faire, où la recherche devrait être du retrieval, et où un pipeline LLM exige la même rigueur que nous réservions au code de paiement : des evals avant les déploiements, de l'observabilité sur chaque appel, un budget de coûts que quelqu'un surveille vraiment.

Il se trouve que c'est le problème d'ingénierie le plus intéressant que j'aie jamais touché. Il est aussi largement non documenté. Tout le monde écrit sur les agents greenfield et les démos ; presque personne n'écrit sur l'intégration de l'intelligence dans un système qui a des clients payants et qui n'a pas le droit de tomber en panne un mardi.

Alors je fais la deuxième chose inconfortable : je documente tout en public, chaque semaine. Concrètement, cela veut dire :

• Des décisions d'architecture, avec les contraintes qui les ont imposées — pas la version aseptisée écrite après coup.
• Des échecs, parce que la stratégie de chunking qui s'est effondrée sur de vraies pages Notion m'a plus appris que celle qui a fonctionné.
• Des benchmarks et des evals, avec des chiffres, pour que « ça marche mieux maintenant » veuille dire quelque chose.

Si vous êtes un ingénieur full-stack traditionnel qui sent le même sol bouger sous ses pieds, ou si vous transformez un système traditionnel en système AI-native, suivez le fil. Je n'ai pas de formation à vendre. J'ai une plateforme legacy, une deadline, et une habitude d'écriture hebdomadaire dont je suis désormais publiquement responsable.