Le 25 septembre 2026, Hostinger a publié un retour d’expérience sur des modèles de programmation confrontés à des travaux réels. L’étude rapporte notamment un échec commun à prendre en compte une contrainte déjà présente dans le code : un bon motif pour évaluer votre agent sur les règles de votre propre application.
1. Préparer un exercice représentatif
Choisissez une petite évolution déjà comprise par votre équipe, par exemple l’ajout d’un champ facultatif dans un formulaire et son API. L’exercice doit toucher plusieurs couches sans nécessiter de données de production. Utilisez une copie isolée du dépôt, avec des dépendances figées et des services de test.
Écrivez les critères avant de lancer l’agent. Le champ doit être enregistré lorsqu’il existe, les anciens clients doivent continuer à fonctionner et les erreurs doivent conserver le format habituel. Ajoutez une contrainte locale documentée ailleurs dans le dépôt : convention de validation, traitement des valeurs vides ou contrôle d’accès.
Conservez un test indépendant de cette contrainte. Ne donnez pas à l’agent la solution d’un ancien correctif. Vous cherchez à savoir s’il retrouve la règle et l’applique, pas s’il reproduit un changement déjà visible.
2. Demander des preuves de compréhension
Avant l’édition, demandez à l’agent de citer les fichiers qui définissent le contrat de l’API et une implémentation comparable. Faites distinguer ce qu’il a effectivement lu de ce qu’il suppose. Une liste de chemins inventés ou non consultés ne constitue pas une analyse.
La grille suivante est un exemple de recette interne :
| Critère | Preuve attendue |
|---|---|
| Compatibilité | Ancienne requête encore acceptée |
| Validation | Valeur invalide refusée correctement |
| Autorisation | Utilisateur non autorisé toujours bloqué |
| Cohérence | Convention locale conservée |
| Complétude | Interface et API traitées ensemble |
Laissez ensuite l’agent travailler avec un budget fixé à l’avance. Notez les interventions humaines : une solution qui nécessite plusieurs indications peut rester utile, mais son coût de supervision doit être visible.
Ne jugez pas la qualité au nombre de fichiers modifiés. Un changement court peut être complet ; un grand diff peut manquer le comportement essentiel.
3. Relire comme une modification humaine
Exécutez les contrôles habituels du projet et le test indépendant préparé au départ. Inspectez séparément la logique d’autorisation, les migrations éventuelles et les changements de dépendances. Des tests écrits uniquement par l’agent peuvent partager son interprétation erronée.
Relevez les exigences satisfaites, les régressions et les minutes de correction humaine. Si vous comparez deux modèles, repartez du même état initial avec les mêmes outils et limites. Évitez de transformer un petit échantillon en classement universel.
Acceptez l’agent pour ce type précis de maintenance seulement lorsque les critères sont remplis et que le correctif reste compréhensible pour votre équipe. La fusion et le déploiement suivent ensuite votre procédure normale de revue.
Sources : Hostinger, expérimentation de modèles de programmation.