Lorsqu’on utilise sérieusement un agent de programmation IA, la première surprise n’est pas son intelligence.
C’est plutôt :
« À quel moment est-ce qu’il rentre chez lui ? »
Recherche la journée, implémentation le soir, tests la nuit, bug ajouté après minuit. Le lendemain matin, l’agent corrige encore quelque chose.
Une équipe humaine devrait gérer travail de nuit, heures supplémentaires, relais, fatigue et planning. Pour l’IA, les contraintes deviennent le forfait, le quota, le contexte, les outils et la fiabilité.
Puis apparaît un phénomène étrange :
un quota prévu pour une semaine peut disparaître en quelques jours.
Au début il semble immense. Peu après, le système dit en pratique : « Vous l’avez déjà beaucoup trop fait travailler cette semaine. »
Le droit du travail a disparu pour réapparaître sous forme de limite d’utilisation.
Plus de quota, plus de choses à lui demander
Quand la limite augmente, l’utilisateur cesse d’économiser.
Il délègue aussi ce qu’il faisait auparavant lui-même.
Une simple recherche devient :
recherche→implémentation→test→correction→nouveau test→lecture des logs→nouvelle correction.
Même une très grosse augmentation peut donc être consommée rapidement.
120 articles écrits, mais seulement 116 retrouvés sur le site
Supposons que l’IA écrive 120 articles et enregistre les 120. Seuls 118 entrent dans la liste d’attente pour publication, et seuls 116 sont confirmés sur le site.
Ces chiffres côte à côte montrent où chercher : 2 se sont arrêtés après l’enregistrement, puis 2 autres plus loin. L’écriture peut très bien avoir réussi. L’enregistrement peut échouer, le titre ou d’autres informations être refusés, ou une traduction rester bloquée. L’article peut même être publié sans apparaître dans la liste.
Écrits 120 → enregistrés 120 → en attente de publication 118 → confirmés sur le site 116.
Ce sont des chiffres d’exemple, pas un bilan réel. Compter aussi les étapes intermédiaires permet de retrouver les 4 manquants. Un échec peut arriver. Le pire, c’est que le travail disparaisse sans laisser de trace.
Prendre le temps de réfléchir quand le même blocage revient
Si les corrections ordinaires avancent, on continue avec le mode habituel. Si la même étape échoue sans cesse, on demande à un mode qui réfléchit plus longtemps de classer les causes possibles et l’ordre des réparations. Une fois le plan prêt, on revient au travail courant.
Un mode supérieur peut consommer davantage de quota. Je préfère le garder pour « Pourquoi cet article ne se publie-t-il pas ? » plutôt que pour chaque petite modification. Pas besoin d’un chirurgien spécialiste à chaque changement de pansement. Quand on ne sait pas où opérer, il devient précieux.
Recommencer les articles bloqués, pas toute la série
Quand un article manque, on note son identifiant et la raison de l’arrêt. On réessaie si l’opération peut se faire sans danger. Si elle échoue encore au même endroit, une personne ou une autre IA examine le cas. Inutile de réécrire tous les articles depuis le début.
En attendant le retour du quota, on peut réunir les erreurs et les étapes pour les reproduire. Si le service rétablit sa capacité périodiquement, les problèmes importants seront prêts quand elle reviendra. Le moment et la quantité dépendent du service.
L’article est-il arrivé ?
Une personne décide encore quels articles passent en premier, quoi vérifier avant publication et ce qui ne doit pas être retenté automatiquement.
Ensuite, je préfère voir quel article s’est arrêté sans fixer l’écran toute la journée. Plus l’IA écrit vite, plus un seul article bloqué à l’enregistrement ou à la publication se remarque.
« L’IA peut encore travailler. Mais où est passé cet article ? »
Si le collègue de nuit réécrit sans cesse le même article, c’est le quota que l’on gaspille, pas son sommeil.
