Transposition libre, à l'ère de l'IA, de l'article d'Arnaud Mazin « "pet vs. cattle", de l'artisan du serveur à l'artisan codeur » (OCTO Talks!, 20 décembre 2016). L'original parlait du métier d'Ops ; celui-ci parle du métier de développeur face à l'IA générative.
En 2016, on racontait comment l'administrateur système était passé, en quatre âges, de l'artisan qui choyait ses serveurs un par un (« pet ») à l'artisan codeur qui pilotait des troupeaux de machines par du code versionné et testé (« cattle »). Dix ans plus tard, c'est au tour du développeur de vivre sa propre mue. L'IA générative joue, pour le code, le rôle qu'avaient joué la virtualisation puis l'Infrastructure as Code pour les serveurs.
Pour suivre cette évolution, gardons un fil rouge : ajouter une fonctionnalité « favoris » à une application web — un modèle de données, un endpoint d'API, un bout d'interface, et les tests qui vont avec. Une feature banale, le genre qu'on écrit cent fois dans une carrière. Regardons comment on la réalise à chaque âge.
De nombreux développeurs entretiennent une relation affective avec leur code. Ils connaissent chaque fonction individuellement, se souviennent de la raison d'être de chaque ligne, retiennent par cœur la signature des API qu'ils utilisent le plus. Le code est un pet : on l'écrit à la main, on le relit avec soin, on le caresse dans le sens du poil.
On ouvre l'éditeur, on écrit le modèle, on écrit l'endpoint en se rappelant de la syntaxe du framework, on écrit le HTML, on lance le serveur, on rafraîchit le navigateur, on clique, on regarde — « ça marche ». Et on recommence pour la feature suivante.
$ vim src/models/favorite.js # le modèle, à la main
$ vim src/routes/favorites.js # l'endpoint — de mémoire, la syntaxe d'Express
$ vim src/views/favorites.html # l'interface, balise par balise
$ node server.js
# clic… clic… « ça marche »Niveau de confort : ⭐⭐⭐ (3/5)
Fonctionne très bien quand :
- le projet est petit ;
- il y a peu de fonctionnalités à livrer ;
- on est seul ou presque sur la base de code ;
- on a le temps.
Limitations :
- ne passe pas à l'échelle d'un produit qui grossit ;
- la vélocité dépend entièrement de la mémoire et de la dextérité d'une personne ;
- bus factor de 1 : la connaissance vit dans une seule tête.
Les bases de code grossissent, les frameworks se multiplient, et personne ne peut plus tout retenir. L'éditeur devient intelligent : complétion contextuelle, snippets, génération de boilerplate, puis les premiers assistants qui proposent la ligne suivante avant même qu'on l'ait pensée. C'est le règne du « tab, tab, tab ».
La feature avance plus vite : on tape addFavorite, l'assistant propose le corps de la fonction, on appuie sur Tab, on continue. Mais chaque suggestion doit être surveillée, relue, parfois corrigée. L'outil accélère la frappe ; il ne garantit pas la justesse.
// src/services/favorites.js
function addFavorite(userId, itemId) {
// l'assistant propose tout le corps → Tab
return db.favorites.insert({ userId, itemId, createdAt: Date.now() });
}
// je tape « remove », il complète removeFavorite() → Tab$ npm run dev # hot reload, je vérifie à l'œil que ça tourneNiveau de confort : ⭐⭐ (2/5)
Fonctionne très bien quand :
- la complétion fait gagner du temps sur le code répétitif ;
- le développeur garde la main et relit chaque suggestion.
Limitations :
- on finit par accepter des suggestions sans vraiment les lire ;
- une dette silencieuse s'accumule (patterns recopiés, subtilités ignorées) ;
- l'illusion de vitesse masque l'absence de filet (toujours pas de test).
L'automatisation de la production de code devient évidente. On ne complète plus une ligne : on demande un fichier, une fonction, une feature entière, en langage naturel. Le développeur prompte, l'IA génère. C'est l'approche cattle appliquée au code : on génère, on jette, on régénère, sans attachement particulier à ce qui sort.
> « Génère-moi un modèle Favorite, un endpoint POST /favorites et
DELETE /favorites/:id, et le composant React qui va avec. »
$ git checkout -b favorites
# l'IA produit quatre fichiers d'un coup
# je les colle, j'ajuste deux imports, ça compile, l'écran s'afficheC'est redoutablement efficace : des heures de travail compressées en minutes, la fin du boilerplate à la main, la capacité à démarrer n'importe quelle feature sans connaître par cœur le framework. Mais cela soulève des questions existentielles sur la maîtrise et la qualité : est-ce que je comprends vraiment ce code ? est-ce que je lui fais confiance ?
Niveau de confort : ⭐⭐⭐ (3/5)
Fonctionne très bien quand :
- « ce qui a été généré ressemble à ce qui marche d'habitude » ;
- la feature est standard, mille fois vue dans les données d'entraînement ;
- le code généré tient lieu de première intention, vite obtenue.
Limitations :
- absence de tests : impossible de vérifier instantanément que ça fonctionne ;
- hallucinations — API inexistantes, contrats subtilement faux ;
- du code qui marche « par hasard » et qu'on ne saurait pas réparer ;
- dès qu'on édite à la main le code généré, la prochaine régénération efface tout.
En observant les meilleures équipes, le développeur redécouvre un écosystème de bonnes pratiques — les siennes, en réalité, mais appliquées à un nouvel objet. L'IA cesse d'être un distributeur de bouts de code pour devenir un agent que l'on pilote, dans une boucle outillée.
Pratiques qui reviennent au premier plan :
- les tests d'abord : on demande à l'agent d'écrire les tests avant l'implémentation (TDD), et le vert devient le contrat ;
- la revue de code humain × IA : on relit ce que l'agent produit, on lui fait relire ce qu'on produit ;
- le versionning de l'intention : la spec, le contexte et les conventions sont écrits et commités (
docs/specs/,CLAUDE.md), pas seulement le code ; - la qualité outillée : linters, formatage, intégration continue, le tout exécuté en boucle par l'agent lui-même.
$ git checkout -b feature/favorites
$ vim docs/specs/favorites.md # je rédige la spec : comportement, cas limites
$ vim CLAUDE.md # je soigne le contexte donné à l'agent
$ claude "implémente les favoris en TDD selon docs/specs/favorites.md"
# l'agent écrit les tests D'ABORD, puis l'implémentation
$ npm test # rouge → vert
$ npm run lint # syntaxe et conventions
$ git commit -m "feat(favorites): add bookmarks (#1234)"
$ gh pr create # revue humain × IA
# CI au vert → mergeLe développeur pratique ici une forme de software craftsmanship déplacée : il ne cisèle plus chaque ligne, il cisèle le contexte, la spec et les tests qui contraignent l'agent. La beauté, l'expressivité et la maintenabilité restent les buts ; les moyens ont changé.
Niveau de confort : ⭐⭐⭐⭐ (4/5)
Fonctionne très bien quand :
- plusieurs niveaux de tests forment le filet de sécurité ;
- toute l'intention (specs, conventions, contexte) est versionnée au même titre que le code.
Limitation : « Non, stop, ça marche. »
L'agent et son harnais — la spec, le contexte, les tests, la boucle d'intégration — deviennent le nouvel animal de compagnie, celui dont on prend désormais le plus grand soin. La transformation du métier de développeur n'est pas un reniement de ses valeurs : c'est un déplacement de l'objet d'attention. On est passé du soin porté à chaque ligne écrite à la main, au soin porté au contexte et à l'automate qui génère le code — en conservant intact le goût du travail bien fait.
De nouveaux défis s'annoncent déjà : des agents autonomes enchaînant plusieurs étapes sans supervision, des fleets d'agents travaillant en parallèle sur la même base de code, des environnements de développement éphémères créés et détruits à la demande, et de l'IA qui relit l'IA. Les durées de vie d'un bout de code deviennent encore plus courtes — parfois régénéré à chaque itération. Mais les bonnes pratiques remises au goût du jour à ce quatrième âge — tests, specs versionnées, revue, intégration continue — sont précisément ce qui prépare le développeur aux bouleversements à venir.
Inspiré de « "pet vs. cattle", de l'artisan du serveur à l'artisan codeur », Arnaud Mazin, OCTO Talks!, 2016.