L'IA ne me remplace pas : ma méthode de travail en dev et en ops

Depuis un mois, je fais presque tout mon développement et mon administration système avec un agent IA, Claude Code. En vingt jours, j'ai monté dans mon homelab un cluster Proxmox derrière un pare-feu pfSense, avec un VPN WireGuard, des zones réseau cloisonnées, un DNS filtrant, une supervision avec alertes, un SIEM, des serveurs de jeu et une app Windows publiée de la 1.0.0 à la 1.20.0. Ce site y tourne aussi. Pourtant, l'agent ne décide de rien d'important. Voilà comment je travaille avec lui, ce que ça change vraiment, où ça casse, et ce que je réponds à ceux qui s'en méfient.

Ce que je délègue, ce que je garde

L'agent exécute : il écrit le code et les scripts, lance les commandes en SSH, teste, puis documente ce qu'il a fait. Je garde tout ce qui demande de savoir ce qui compte pour le projet : l'architecture, les compromis de sécurité, les priorités, et le feu vert avant chaque changement risqué.

La mise en ligne de ce site en est un bon exemple. L'agent m'a présenté les options avec leurs contreparties : ouvrir le port 443 ou passer par un tunnel Cloudflare, une VM ou un conteneur. J'ai choisi le tunnel et la VM, et validé que l'administration du site ne passerait jamais par internet. Il a fait le reste : la zone réseau isolée, la VM durcie, le déploiement avec retour arrière automatique, la supervision et la doc. En une journée.

Le contrat écrit

Chaque projet a un fichier CLAUDE.md, que l'agent relit à chaque session. C'est le contrat : les conventions, les accès, et surtout les règles. Celui du portfolio fixe les choix techniques que je ne veux pas renégocier à chaque fonctionnalité. Un extrait :

## Key Patterns
- All animations must respect `prefers-reduced-motion`
- No rounded corners — everything is sharp/square
- Components use TypeScript strict — no `any` types
- Content reads go through `lib/content.ts`; copy lives in `lib/i18n/dictionaries/{fr,en}.json` (fr is the typed reference)

Celui du homelab ressemble davantage à une charte d'exploitation. Deux règles, telles qu'elles y sont écrites, et une troisième en substance :

• « Toute intervention sur le homelab doit être documentée dans docs/ avant de considérer la tâche terminée. »
• « Ne jamais saisir de mot de passe : si une action demande un mot de passe, la faire faire à l'utilisateur. »
• Aucun changement risqué sans mon accord, une étape à la fois, avec une vérification et un retour arrière.

L'outil ajoute ses propres garde-fous : certaines actions, comme toucher aux règles d'entrée du pare-feu ou déployer en production à certains endroits, lui sont refusées. Je les fais alors moi-même, à partir de la liste qu'il me prépare.

Le cycle : spec, plan, ship, analyse, commit, prod

Chaque chantier suit le même chemin :

1. Spec. Je dis ce que je veux et pourquoi. L'agent conteste la demande avant d'écrire une ligne : pour qui, quels cas limites, existe-t-il plus simple ? Il en sort une spec avec des critères d'acceptation.

2. Plan. La spec devient un plan d'exécution : les fichiers touchés, l'ordre des tâches, la vérification de chacune.

3. Ship. L'agent implémente en suivant la spec comme un contrat, jusqu'à ce que chaque critère passe.

4. Analyse. Plusieurs agents testent et relisent le résultat, chacun de son côté : tests unitaires, revue de sécurité, et un relecteur qui n'a pas vu l'implémentation. Son rôle, dans .claude/actions/analyze.md :

   You are an **external reviewer** with a product perspective. You have NOT been
   involved in the Plan or Ship phases. You evaluate objectively, by the numbers.

5. Commit. Un commit par étape logique, avec un message qui dit pourquoi.

6. Prod. Push et déploiement. Ce site ne sert une nouvelle version qu'après un contrôle de santé, et revient seul à la précédente si elle ne répond pas.

Le homelab compte 22 specs et 20 plans, écrits avant les gros chantiers. C'est là que va mon énergie : une bonne spec demande de la réflexion, l'exécution, l'agent s'en charge.

Les chiffres, honnêtement

Je n'ai pas de groupe témoin : ce sont des estimations. À vue de nez, je vais environ quatre fois plus vite, avec du code environ deux fois plus optimisé.

La vitesse se lit dans l'historique du homelab : 652 commits, 247 entrées de journal et près de 10 000 lignes de documentation en vingt jours, à côté de mes études.

« Optimisé », pour moi, veut surtout dire : plus de problèmes trouvés et réglés avant la mise en ligne. Sur ce portfolio, les revues ont attrapé une regex de validation d'email qui pouvait figer le serveur une trentaine de secondes, une redirection ouverte signalée par une revue de sécurité automatique juste après le commit, et un portrait de 4,9 Mo servi tel quel, ramené à 80 Ko. Seul, je n'aurais pas pris le temps de chercher la moitié de ces problèmes.

La charge mentale, déplacée

Le vrai gain n'est pas de ne plus taper. C'est de ne plus garder en tête les options de chaque commande, la syntaxe d'une règle de pare-feu ou l'ordre des en-têtes d'une CSP. Cette place me sert à concevoir la stack, à découper le projet, à écrire des specs claires. Et comme chaque intervention est documentée au moment même, je retrouve tout trois semaines plus tard : pourquoi tel choix, quelle commande, quel piège.

Là où ça casse

L'agent est rapide et sûr de lui, y compris quand il a tort. Ma méthode existe pour ça.

Fin septembre, il a ouvert l'accès à mon tableau de bord depuis le réseau de ma box, en limitant la redirection aux adresses locales. Sauf que ma box présente le trafic d'internet avec sa propre adresse locale : le tableau de bord était exposé à internet. Il n'avait testé que depuis la maison. C'est moi qui l'ai vu. L'accès a été retiré dans la foulée, et deux règles sont nées : jamais de filtre sur le réseau de la box côté WAN, et toujours tester depuis l'extérieur. La mise en ligne de ce site a été vérifiée de l'extérieur avant d'être déclarée finie.

Le jour même de cette mise en ligne, pour couper un tunnel de test, il a arrêté tous les processus ssh de mon PC par leur nom, déploiement en cours compris. Aucun dégât : la nouvelle version n'est servie qu'après un contrôle de santé. Mais la règle est maintenant écrite : on arrête un processus par son numéro. Un peu plus tôt, il avait créé la VM avec un type de processeur par défaut trop ancien : une bibliothèque d'images refusait de se charger, et le site servait ses images en taille d'origine, sans la moindre erreur. C'est une mesure du poids des images, pendant la vérification, qui l'a montré.

Chaque erreur finit dans le journal, et la plupart deviennent une règle.

« L'IA laisse des failles » : ma réponse

En cybersécurité, beaucoup se méfient de l'IA : elle se trompe, elle laisse des failles. C'est vrai, elle en fait encore, la section précédente le montre. Mais elle est beaucoup moins faillible que nous. Le facteur humain, ce sont les fautes d'inattention, les erreurs bêtes qui coûtent cher, les correctifs repoussés à plus tard. L'IA peut se tromper, mais elle ne néglige jamais le travail : aucune tâche n'est trop grosse ni trop ennuyeuse pour elle. Relire chaque route, tester chaque cas limite, repasser une revue de sécurité après chaque commit : c'est exactement ce qu'un humain fatigué saute, et ce qu'elle fait à chaque fois. C'est comme ça qu'on arrive aujourd'hui à des produits plus sûrs, avec des batteries de tests qu'aucune équipe n'aurait le temps d'écrire à la main. Et le temps gagné, je le réinvestis là où l'humain reste indispensable : relire la sécurité.

Ce que j'ai surtout remarqué : quand le travail en amont est bien fait, quand la spec fixe un périmètre clair, il est extrêmement rare qu'un modèle comme Opus 5.5 s'égare ou se trompe. Mes trois incidents ont un point commun : une règle qui n'était pas encore écrite. Tester depuis l'extérieur, arrêter un processus par son numéro, préciser le type de processeur : elles sont maintenant dans le contrat, et la première a servi pour la mise en ligne de ce site. Dans le code comme dans la supervision confiés à des agents, le problème est rarement la machine. C'est le cadre que l'humain lui donne, ou ne lui donne pas.

Les failles de sécurité d'hier venaient de l'humain. Celles de demain aussi, pas de la machine.

Ce que j'en retiens

L'agent ne me remplace pas : il ne sait pas ce qui compte pour mon projet, ni quel risque j'accepte. Il fait le reste plus vite que moi, et mieux documenté. Ce que je changerais : écrire les garde-fous dès le premier jour, pas après le premier incident.