Contexte et motivation
L’auteur, titulaire d’un doctorat en physique d’instrumentation, a choisi de créer un site web pour sa collection de machines à écrire. Il précise que le temps disponible était limité entre son travail, la parentalité et la gestion de la collection, ce qui l’a poussé à explorer l’automatisation du développement via l’intelligence artificielle. Le projet a débuté au printemps 2026, période où il a constaté que la version de Claude déployée chez ses collègues était capable de produire du code fonctionnel en quelques minutes.
Cette prise de conscience a coïncidé avec l’émergence d’un workflow à agents multiples : un agent génère le code, un second exécute les tests, un troisième examine les résultats et valide la conformité avec la demande initiale. Le modèle Claude, bien que non identifié précisément, a servi de moteur central à ce processus, remplaçant les itérations manuelles habituelles.
Architecture agentique de génération
Le pipeline repose sur trois agents distincts orchestrés par des prompts spécifiques. L’agent « builder » a produit un squelette d’application Mojolicious, un framework Perl souvent utilisé pour les services web légers. L’agent « tester » a lancé des suites de tests automatisés dans un cluster Kubernetes, assurant la conformité aux exigences fonctionnelles. Enfin, l’agent « reviewer » a comparé les sorties aux critères définis, en s’appuyant sur les logs générés. Aucun IDE n’a été ouvert ; l’auteur a uniquement consulté le code via Vim, confirmant une approche véritablement « hands‑off ».
Le site intègre un moteur de tags doté d’un petit langage de requête, par exemple single-element+!index pour afficher un typewriter précis, ou index+!single-element pour inverser la vue. Ces fonctionnalités, générées automatiquement, n’auraient pas été implémentées dans le même délai par l’auteur seul. Le déploiement s’est fait via des conteneurs Docker, orchestrés par Kubernetes, ce qui a permis de mettre à jour le service sans intervention manuelle sur le code source.
Analyse des limites et risques
Malgré la productivité accrue, l’auteur observe des cas d’« AI slop » : hallucinations syntaxiques, références à des bibliothèques obsolètes et comportements inattendus lorsqu’une demande dépasse la connaissance du modèle. Ces défauts nécessitent une supervision humaine pour réorienter l’agent et corriger les erreurs avant la mise en production. Le manque de visibilité sur les versions exactes des dépendances introduit également un risque de vulnérabilité non détectée.
Sur le plan ergonomique, le processus réduit la résolution de problèmes et l’apprentissage actif du développeur. La dépendance à un modèle propriétaire comme Claude crée une chaîne de confiance fragile : si le service devient indisponible ou change de politique, la capacité à maintenir le site pourrait être compromise. Enfin, l’absence de revue de code humaine augmente le potentiel d’introduire des failles de sécurité, notamment dans les points d’entrée API du moteur de tags.
