Skip to content
PKResources
Plan de la formation

Ingénierie agentique : la formation pratique · Module 4: Les boucles de vérification

Types, linters et rétroaction rapide

Un agent itère des dizaines de fois par tâche. Donnez-lui d’abord des vérifications rapides et peu coûteuses, une seule commande pour les lancer, et aucun moyen de les éteindre en douce.

Leçon 14 / 24 · ⏱ 7 min

Les tests disent à l’agent si le comportement est bon. Les types et le linter lui disent, en quelques secondes, que quelque chose cloche avant même d’en arriver là.

Un agent lance ses vérifications plusieurs fois par tâche. Plus chaque boucle est rapide, plus il fait de boucles, et moins d’erreurs survivent jusqu’à votre revue.

L’échelle de rétroaction

peu coûteux, secondescoûteux, minutesFormateurTypesLinterTests unitairesIntégrationBout en boutà chaque itérationune seule commande de vérificationintégration et bout en bout : avant de rendre le travail
Illustratif, pas mesuré : ordonnez vos vérifications de la moins coûteuse à la plus coûteuse. L’agent devrait passer par les échelons rapides à chaque itération, et par les lents avant de rendre son travail.

Une seule commande pour la boucle

Si votre dépôt exige quatre commandes dans un ordre précis pour valider un changement, l’agent finira par en sauter une. Regroupez les échelons rapides dans une seule commande de vérification et parlez-en à l’agent dans votre fichier d’instructions (leçon 2.2).

## Vérifier ton travail
- Lance la commande de vérification après chaque changement : elle
  formate, vérifie les types, passe le linter et lance les tests
  unitaires des fichiers touchés.
- Avant de dire que tu as terminé, lance toute la suite de tests une fois.
- N'ajoute jamais de commentaires qui désactivent le linter, d'échappatoires
  de types ou de tests ignorés pour faire passer une vérification.
  Si une règle te semble fausse, arrête et demande.

Les types et les règles de lint sont aussi des specs

Des types stricts transforment des familles entières d’erreurs en erreurs instantanées. Renommer une fonction et oublier un appel, passer le mauvais format d’objet, oublier un cas nul : le vérificateur de types le signale à l’agent avant qu’un seul test roule.

Les règles de lint font pareil pour les conventions. Chaque règle encodée (« la couche UI n’importe jamais le module de base de données ») est une ligne que vous n’avez plus à répéter dans chaque brief.

Jeu : quelle vérification l’attrape?

Classez chaque erreur selon la vérification la moins coûteuse qui l’attrape de façon fiable.

🎮 Types, linter ou tests?

1 / 10 · Pointage: 0

Avant de continuer

✅ À retenir

0 / 4 complété