Comment je travaille

Un développement assisté par IA, dans des garde-fous que la CI impose.

Je construis des logiciels avec des agents IA au quotidien, surtout Claude Code. L'essentiel de ce travail n'est pas de la rédaction de prompts. C'est rendre une base de code lisible pour l'agent, et faire échouer ses erreurs bruyamment plutôt qu'en silence.

Télécharger le PDF

Une hiérarchie d'instructions

Un fichier d'instructions à la racine porte les règles valables pour tout le dépôt. Chaque zone a le sien, et un fichier plus profond prime sur la racine pour son sous-arbre. Les fichiers spécifiques à un agent se contentent de pointer vers ceux-là, donc plusieurs agents de code lisent les mêmes règles et rien n'est maintenu deux fois. Quand un agent connaît le mode d'échec derrière une règle, il l'applique à des cas que personne n'a listés : chaque règle non évidente porte donc sa raison.

  • AGENTS.mdrègles du dépôt : pas de valeurs magiques, lint vert, âge des dépendances
  • ├─ backend/AGENTS.mdAPI, base de données, authentification, validation
  • ├─ frontend/AGENTS.mdroutage, état, styles, tests
  • └─ CLAUDE.mdpointeur vers les fichiers AGENTS.md

Les règles deviennent des vérifications

Une règle qu'un agent peut ignorer reste une suggestion. Une erreur récurrente devient une vérification qui échoue : la compilation refuse tant que les types de base de données générés n'existent pas, un job CI échoue quand un contrat d'API dérive de son schéma, une règle ESLint rejette les transactions SQL écrites à la main hors de la couche base de données, Stylelint rejette les couleurs codées en dur, et une dépendance publiée la veille ne peut pas être installée à la main.

Un échec réel, pas hypothétique : Stylelint qui rejette une couleur codée en dur.
$ npm run lint:styles

app/components/Example/Example.scss
  12:3  ✖ Unexpected hex color "#f5a623"   color-no-hex

1 problem (1 error, 0 warnings)

Des vérifications à chaque changement

Chaque pull request fait tourner le lint, les tests et une compilation, côté backend et frontend, plus un job qui échoue si un contrat généré n'est plus à jour. Le jeton d'accès de la CI est en lecture seule par défaut, donc le code d'une pull request n'hérite jamais des droits d'écriture.

Des vérifications sur les documents générés

Les agents génèrent aussi des documents, pas seulement du code, et un document peut être faux d'une façon qu'aucun test unitaire ne voit. Mes CV sont générés depuis une configuration typée puis rendus en PDF, et chacun doit passer une vérification avant d'être envoyé : exactement une page, un nombre minimal de liens cliquables, un budget de mots, les compétences requises présentes, les mots interdits absents.

Des compétences réutilisables

Onze compétences, partagées entre les agents de code que j'utilise. Chacune est une procédure avec ses propres garde-fous : génération de composants et de stores, rédaction de user stories dans le format exact d'un projet, un audit UI et UX qui pilote un vrai navigateur sur trois largeurs d'écran et n'applique que les correctifs qui passent le lint et les tests, et un audit de sécurité.

La preuve, pas une affirmation

J'ai porté ce même modèle vers Rust puis vers Go, chacun en un à deux jours, assisté par IA. Ce site est construit de la même façon, et une fois public, son dépôt en est l'exemple.