Comment l’IA a inversé ma manière de travailler en tant que développeur
Introduction
Pendant 10 ans, j’ai travaillé comme beaucoup de développeurs.
Un client arrive.
Il a des specs.
Je les exécute.
Je pose quelques questions techniques.
Je choisis l’architecture.
Je code.
Je livre.
Le centre de gravité de mon travail était le code.
Puis l’IA est arrivée.
Et, contre toute attente, elle m’a forcé à ralentir.
Avant : exécuter proprement
Mon rôle était simple :
- Comprendre la demande
- Choisir une stack
- Implémenter efficacement
- Optimiser si nécessaire
Plus j’étais rapide, plus j’étais performant.
La valeur était dans l’implémentation.
Le choc : produire du code n’est plus rare
Avec l’IA, produire du code n’est plus un avantage compétitif.
Je peux générer en quelques minutes :
- des composants React
- des endpoints backend
- des tests unitaires
- des migrations SQL
- de la documentation technique
Mais j’ai découvert un problème majeur :
L’IA code exactement ce que vous lui demandez.
Même si ce que vous demandez est flou.
Et plus la demande est floue, plus le système devient incohérent.
L’inversion complète
Avant, je commençais par coder.
Aujourd’hui, je commence par :
- Définir précisément les invariants métier
- Faire rédiger des spécifications détaillées
- Formaliser les flux utilisateurs
- Délimiter clairement les responsabilités
- Concevoir l’architecture cible
Seulement après, je laisse l’IA produire.
Le code est devenu la dernière étape.
L’IA exige un cadre strict
Contrairement à un développeur expérimenté,
l’IA ne comprend pas l’intention produit.
Elle extrapole.
Si l’architecture est floue :
- Elle duplique la logique
- Elle mélange les couches
- Elle crée des dépendances implicites
- Elle invente des abstractions inutiles
- Elle hallucine des comportements
On parle d’"hallucinations".
Mais ce sont souvent des hallucinations de cadrage.
L’IA amplifie la qualité de la pensée en amont.
Si le cadre est flou → elle amplifie le flou.
Si le cadre est clair → elle amplifie la rigueur.
Ce que ça change concrètement
Aujourd’hui je passe plus de temps à :
- Challenger les specs
- Faire préciser les règles métier
- Définir des contrats d’API stricts
- Écrire de la documentation structurante
- Concevoir des boundaries claires (Clean / Hexa)
Et moins de temps à écrire du code brut.
Je ne suis plus un exécutant.
Je suis devenu :
- Traducteur entre vision produit et implémentation
- Garant des invariants métier
- Architecte des frontières
- Contrôleur de cohérence
Paradoxe : je code moins, mais je livre mieux
Le temps de production a diminué.
Le temps de réflexion a augmenté.
Mais la qualité globale du système est supérieure :
- Moins de régressions
- Moins d’effets de bord
- Moins de dette invisible
- Moins d’architecture accidentelle
L’IA ne remplace pas l’architecte.
Elle le rend indispensable.
Ce que j’ai compris
L’IA ne récompense pas les développeurs rapides.
Elle récompense ceux qui pensent clairement.
Dans un monde où coder devient trivial,
structurer devient stratégique.
Et je pense que le rôle du CTO évolue exactement dans cette direction :
- Moins d’expertise syntaxique
- Plus de clarté structurelle
- Moins d’exécution
- Plus de cadrage
Conclusion
L’IA n’a pas augmenté ma vitesse.
Elle a élevé mon niveau d’exigence.
Elle m’a obligé à mieux comprendre le produit.
À mieux formaliser les règles.
À mieux penser l’architecture avant d’écrire une seule ligne.
Et finalement, elle m’a fait évoluer.
Moins développeur.
Plus architecte.
Moins exécutant.
Plus stratège.