La preuve que l'IA rend les développeurs paresseux (et la preuve, c'est moi)

On me l’a dit assez souvent pour que je finisse par l’écrire : l’IA rend les développeurs paresseux. Le genre de phrase qu’on lâche en réunion avec un petit sourire, comme un constat triste sur la jeunesse qui ne sait plus poser une jointure SQL à la main.

D’habitude, à ce stade de l’article, l’auteur prend sa plus belle voix pour vous expliquer que non, l’IA ne remplace pas la pensée, elle l’augmente, blablabla. Pas ici. Je plaide coupable. Mieux : je viens avec les preuves. Asseyez-vous, je vous fais visiter le dossier d’instruction — c’est-à-dire mon terminal.

Petit avertissement honnête avant d’ouvrir le capot : tout ce qui suit est une infrastructure réelle, que j’utilise au quotidien sur mes projets (Tikerama, Tikego, Wori, Gausoft…). Rien n’est mis en scène pour l’article. C’est précisément ce qui devrait vous inquiéter.

Le décor : un agent qui vit dans le terminal#

Avant les pièces à conviction, le contexte. Je ne parle pas d’aller copier-coller du code depuis une fenêtre de chat. Je parle d’un agent qui habite mon terminal, dans le dossier du projet, avec accès aux fichiers, au shell, à Git — et surtout connecté au reste de mon outillage via le protocole MCP (Model Context Protocol).

MCP, c’est la prise USB des agents : un standard pour brancher un modèle sur des outils externes. Côté serveur, vous exposez des tools (lister des apps, lire des logs, déployer…). Côté agent, le modèle les appelle comme s’il avait des mains. Dans ma config, les serveurs MCP branchés en permanence ressemblent à ça :

• Trois instances Coolify (gausoft, wori, tikerama) — pour piloter mes déploiements depuis le terminal sans ouvrir un seul dashboard ;
• chrome-devtools — un vrai Chrome pilotable (capture, réseau, console, perf, Lighthouse) ;
• Tavily et Exa — recherche et veille web sans quitter la session ;
• code-review-graph — un knowledge graph de mon code (j’y reviens, c’est ma pièce préférée) ;
• context-mode — un bac à sable qui exécute du code sur de gros volumes sans me faire avaler les octets en contexte.

Et je ne tourne pas sur un seul agent : selon la tâche je bascule entre Claude Code, Codex (en gpt-5.5, reasoning effort poussé au maximum) et Pi. Trois harnais, le même outillage MCP dessous. Le terminal est devenu une salle de contrôle.

Maintenant, les preuves.

Pièce à conviction n°1 — Je ne tape plus mes messages de commit#

Je tape commit. C’est tout. Un sous-agent dédié (git-commit-writer) lit git status, puis git diff --staged, comprend l’intention du changeset, le regroupe logiquement, et me propose un message en conventional commits. Je n’écris plus « fix bug » à 23h.

Le détail qui compte : c’est un sous-agent, pas un prompt. Il tourne dans un contexte isolé, avec sa propre liste d’outils restreinte (Read, Grep, Bash en lecture seule). Il ne pollue pas la conversation principale et ne peut pas, par construction, partir modifier mes fichiers. La paresse, oui — mais une paresse cloisonnée.

Pièce à conviction n°2 — Je ne déploie plus à la main#

« Déploie l’API Tikerama en prod. »

Voilà ma contribution au déploiement. Derrière, un sous-agent deploy-captain prend le relais. Il connaît mon infra parce qu’il lit d’abord un fichier INFRA_MAP.md — ma source unique de vérité qui mappe projet → serveur → méthode d’accès :

Il résout la cible, appelle les tools Coolify (list_applications, deploy, application_logs…), et — détail non négociable — demande une confirmation explicite de la cible exacte (serveur + app + environnement) avant toute action qui mute quoi que ce soit. La flemme de déployer, oui. La flemme de mettre un garde-fou, non.

Je gère un parc déjà conséquent de serveurs sous Coolify (l’alternative auto-hébergée à Heroku/Vercel), et c’est sans doute la brique qui me change le plus la vie. Monitorer, déployer, débugger une app : tout passe par l’agent. Coolify expose à la fois un MCP et un CLI — et de plus en plus, je préfère le CLI.

Aparté technique : pourquoi un CLI bat souvent un MCP#

Contre-intuitif, mais réel. Un serveur MCP charge en permanence le schéma de tous ses outils dans le contexte du modèle (chaque tool, ses paramètres, ses descriptions) — ça consomme des tokens même quand vous ne l’utilisez pas, et ça multiplie les allers-retours. Un CLI, lui, l’agent sait déjà s’en servir : c’est du shell, de l’aide intégrée (--help), des sorties texte qu’il parse, des commandes qu’il enchaîne dans un seul tour. Dans pas mal de cas — opérations scriptables, sorties volumineuses, enchaînements — un bon CLI est plus économe et plus puissant qu’un MCP. Coolify fournit les deux ; pour l’ops du quotidien, je recommande le CLI.

Pièce dans la pièce : de zéro à la prod sans toucher au clavier#

Là où ça devient indécent, c’est le cold start d’un projet. Je donne l’idée. L’agent :

1. initialise le repo et le crée sur GitHub via le CLI gh ;
2. développe le projet, commit, push ;
3. branche le repository sur Coolify pour créer l’application ;
4. et — le clou — comme j’ai configuré mon domaine en wildcard DNS (*.mondomaine), il peut fabriquer n’importe quel sous-domaine à la volée : il en propose un lui-même, le configure sur Coolify, TLS compris, et l’app répond.

Je donne une intention, pas une procédure. Il est suffisamment câblé pour faire la chaîne complète — repo → CI → déploiement → sous-domaine public — pendant que je regarde la statusline afficher le coût en dollars. De l’idée à l’URL en prod, sans une frappe de ma part.

Variante managée : Vercel#

Tout ne vit pas sur mon infra. Pour pas mal de fronts, j’utilise Vercel — pas de l’auto-hébergé comme Coolify, mais un service en ligne, et franchement encore plus simple à piloter. Même logique : je bosse en local, je pousse sur GitHub, je pose les prérequis de ce que je veux déployer, et l’agent s’en charge. Et là encore, deux portes d’entrée :

• Le CLI — celui que je recommande pour sa simplicité : tu l’installes, tu configures l’authentification une fois, et c’est réglé. Toutes les sessions suivantes, l’agent gère l’infra sans re-login.
• Le MCP — plus riche en capacités que le CLI quand tu veux aller loin.

Résultat : contrôler les déploiements, débugger, inspecter — comme sur Coolify. Seule limite honnête : je suis sur l’offre gratuite, donc certaines choses sont bridées. Mais pour sortir un front en ligne en deux phrases, c’est imbattable.

Et quand il n’y a pas de Coolify : le VPS nu#

Tout n’est pas dans un PaaS. Certains projets tournent sur un VPS brut. Quand la machine est vierge, la première chose à faire reste la même qu’avant l’IA — sauf que c’est l’agent qui l’exécute : durcir l’accès. Connexion SSH par clé uniquement, mot de passe désactivé, et un pare-feu qui n’ouvre que les ports strictement nécessaires. Je lui dis « sécurise ce serveur fraîchement provisionné » et il déroule les bonnes pratiques. Je configure ensuite un alias SSH (~/.ssh/config) — un ssh monserveur au lieu de retenir user@ip — et l’agent l’utilise comme moi.

À partir de là, autant le dire franchement : l’agent peut littéralement tout faire sur la machine. Il connaît l’intégralité des commandes Linux ; vous lui donnez n’importe quelle instruction, il l’exécute. Sécuriser, déployer, inspecter un conteneur, suivre un journalctl, débugger une appli qui tousse en prod — c’est comme avoir quelqu’un assis à votre place avec un accès root et une mémoire parfaite du manuel. Le cas qui me sert le plus, concrètement, c’est le debug à chaud sur le serveur : isoler pourquoi ça casse, sans monter dix ssh et fouiller à la main.

C’est aussi exactement là que la paresse devient dangereuse. Un agent avec un SSH sans restriction peut, d’une instruction mal formulée, faire n’importe quoi — au sens propre. D’où le même réflexe que pour Coolify : on re-cloisonne. Compte dédié plutôt que root, sudo tracé, commandes destructrices qui passent par une confirmation explicite, et un prod-firefighter qui, lui, reste en lecture seule (pièce suivante). La règle ne change pas : on délègue la corvée, jamais le garde-fou.

Pièce à conviction n°3 — Je ne lis plus les logs en panique#

Quand la prod tousse, je n’ouvre plus dix onglets. Je lance prod-firefighter : un sous-agent strictement en lecture seule. Il se connecte en SSH et via Coolify, lit les logs, inspecte les conteneurs Docker, isole la cause probable — et ne mute jamais rien (pas de restart, pas de deploy). S’il faut agir, il passe le relais à deploy-captain.

C’est volontairement une séparation des pouvoirs : un agent qui diagnostique ne doit pas pouvoir agir dans le même souffle. À 3h du matin, c’est exactement la garantie qu’on veut.

Pièce à conviction n°4 — Je ne note même plus mes propres idées#

« Note ça sur Trello. »

Un petit CLI maison, tcard (zéro dépendance, juste l’API REST Trello), me rédige une carte propre — titre clair, description markdown business-readable — me la montre, et ne la crée qu’après mon OK. Card déposée dans le bon backlog, je suis ajouté comme membre. N’importe quel agent (Claude, Codex, Pi) shell-out vers le même binaire : « log ça sur Trello » marche identiquement partout.

La paresse atteint ici un sommet : je délègue jusqu’à l’acte de me souvenir que j’ai eu une idée.

Pièce à conviction n°5 — Je ne cherche plus dans mon propre code#

C’est la pièce qui ferait pâlir le moi de 2018. Mes projets sont indexés dans un knowledge graph (code-review-graph). Au lieu de grep à l’aveugle, je pose des questions structurelles :

• qui appelle cette fonction ? (callers_of)
• qu’est-ce que ça casse si je touche à ça ? (get_impact_radius)
• quels flux d’exécution sont impactés ? (get_affected_flows)
• est-ce couvert par des tests ? (tests_for)

Le graphe se met à jour tout seul via des hooks à chaque modif de fichier. Résultat : je n’explore plus le code, je l’interroge. Et pour les gros outputs (logs, builds, dumps), context-mode exécute du code dans un bac à sable et ne me renvoie que le résumé — les 700 Ko de log restent dehors, je garde mon contexte pour réfléchir.

Quand la tâche est plus lourde, j’enchaîne carrément une chaîne de sous-agents : scout (rapide, en Haiku, fait la reconnaissance) → planner (produit un plan, sans toucher au code) → worker/reviewer. Une petite équipe, chacun dans son contexte isolé, chacun avec ses permissions. J’ai industrialisé ma propre délégation.

Pièce à conviction n°6 — Je ne me relis même plus (mes hooks le font)#

Là où ça devient gênant pour ma défense : j’ai automatisé jusqu’à la discipline. Des hooks — des scripts déclenchés sur des événements de l’agent (PreToolUse, Stop…) — surveillent mes propres dérives :

• post-edit-lint : après chaque édition d’un .dart ou .py, il lance dart analyze / ruff et réinjecte les erreurs directement à l’agent pour qu’il les corrige dans la foulée. Je ne lance plus le linter ; le linter se lance sur moi.
• pre-read-guard : il bloque la lecture intégrale d’un fichier de plus de 300 lignes sans offset/limit, et me rappelle d’être ciblé. Une muselière anti-gaspillage de tokens.
• git-push-guard : il bloque tout push direct vers main/master/dev sur les repos protégés (les repos d’orga partagés) — feature branch + PR obligatoires — tout en laissant mes repos perso tranquilles. La regex de détection s’arrête au premier séparateur de commande pour ne pas confondre git push origin feat && gh pr create --base main avec un push sur main. Oui, j’ai mis du soin dans le garde-fou de ma flemme.
• statusline : branche · modèle · % de contexte restant · coût $ de la session. Je vois ma paresse facturée en temps réel.
• tts-on-stop : quand l’agent a fini, il me lit sa réponse à voix haute en français (edge-tts, voix Denise). J’ai atteint le stade où je ne lis même plus l’écran ; on me fait la lecture.

À ce point du procès, l’accusation peut se reposer.

Pièce à conviction n°7 — Je n’écris même plus le côté « business »#

Parce que la paresse d’un dev solo ne s’arrête pas au code. J’ai une batterie de slash commands qui couvrent tout le cycle de vie d’un produit :

/idea-hunt (chasser des vraies douleurs récurrentes) → /validate-idea (go/no-go avant la moindre ligne) → /mvp-scope (périmètre pour < 3 semaines en solo) → /pricing (paliers + projection de revenus) → /ship-launch & /distribute (plan de lancement + acquisition Reddit/SEO/cold outreach). Sans oublier /og-image (capture le hero du dev server en 1200×630), /pr, /release (release notes store + tag Git), /ultraplan…

Et une vingtaine de skills spécialisés qui se chargent à la demande : générer des vidéos en HTML (hyperframes), des PDF premium (markpdf), piloter un navigateur (playwright), interroger Sentry… J’ai externalisé non seulement le code, mais la stratégie produit autour du code.

Le verdict : et si la paresse était le métier ?#

Récapitulons les preuves : je ne tape plus mes commits, je ne déploie plus, je ne lis plus mes logs, je ne note plus mes idées, je ne cherche plus dans mon code, je ne me relis plus, je n’écris plus mon marketing. Le réquisitoire est accablant. L’IA m’a rendu paresseux. Coupable, votre honneur.

Sauf qu’il y a un problème avec cette accusation. Regardez bien la liste de ce que je viens de décrire :

• un fichier INFRA_MAP.md pensé comme source unique de vérité ;
• une séparation des pouvoirs entre l’agent qui diagnostique et celui qui agit ;
• des confirmations explicites avant toute mutation de prod ;
• des hooks qui imposent lint, discipline de tokens et protection des branches partagées ;
• un knowledge graph maintenu à jour automatiquement ;
• une chaîne de sous-agents à contextes isolés et permissions restreintes.

Ça, ce n’est pas le portrait d’un flemmard. C’est le cahier des charges d’un ingénieur système qui a passé un temps considérable à construire la machine qui le dispense des tâches barbantes. Bâtir une infrastructure pour ne plus rien faire de pénible est la chose la moins paresseuse qui soit.

Larry Wall, le créateur de Perl, énonçait il y a trente ans les trois grandes vertus du programmeur : la paresse, l’impatience et l’hubris. Et il définissait la paresse comme « la qualité qui vous pousse à faire un grand effort pour réduire la dépense d’énergie globale ». Pas l’oisiveté — l’effort orienté vers l’oisiveté future. Le bon dev a toujours été celui qui automatise la corvée pour ne plus jamais la refaire. L’IA n’a rien inventé ; elle a juste rendu cette vertu spectaculairement accessible.

Alors oui, prenez la phrase telle quelle : l’IA rend les développeurs paresseux. Mais lisez-la jusqu’au bout. Elle déplace le curseur. Tout ce qui était mécanique — réciter un format de commit, cliquer dans un dashboard, grepper un appel de fonction, formater une carte Trello — part dans le harnais. Ce qui reste de mon côté, c’est de décider quoi déployer, quand dire non à une idée, où mettre les garde-fous, et qui a le droit de toucher à la prod. La partie qui a encore besoin d’un humain.

La vérité, c’est que je n’ai jamais autant conçu de logiciel que depuis que je n’en tape presque plus. La paresse, quand on la prend au sérieux, c’est une discipline d’ingénierie à plein temps.

Je plaide coupable. Et je retourne construire la prochaine machine qui me rendra encore plus inutile. C’est, paraît-il, tout le métier.