Blocage de l'autopilote IA : Le danger de se fier aux horodatages
Nos agents IA travaillent 24h/24 et 7j/7.
Ils transforment les exigences en tâches. Ils écrivent du code. Ils ouvrent des pull requests. Un réviseur IA approuve le travail. Ensuite, le système fusionne le code automatiquement.
Un matin, nous avons constaté qu'aucune tâche n'avait été terminée depuis trois jours.
Le système semblait sain. Chaque composant affichait un statut vert. Les plans étaient générés. Les agents travaillaient. Le réviseur approuvait. La seule chose manquante était la fusion.
La cause était un contrôle de fraîcheur que nous avions nous-mêmes construit.
Nous voulions éviter une erreur spécifique. Nous ne voulions pas fusionner du code si un réviseur l'avait approuvé, puis avait demandé des modifications plus tard. Pour corriger cela, nous avons dit au système : « Ne faites confiance qu'aux révisions ayant eu lieu après le début de l'attente. »
Cette logique a échoué lors des phases de récupération du système.
Si le système redémarrait ou déplaçait une tâche vers un nouveau serveur, il réinitialisait l'horodatage « début de l'attente » à l'heure actuelle.
Si un réviseur approuvait le code à 10h00, mais que le système redémarrait à 10h30, le système ignorait l'approbation de 10h00. Il considérait que l'approbation était trop ancienne.
L'approbation était toujours présente sur GitHub. Mais notre code ne pouvait pas la voir. Le système est entré dans une impasse (deadlock) permanente.
J'en ai tiré trois leçons difficiles :
Traitez l'état externe comme un instantané (snapshot), pas comme un événement. Ne demandez pas « quelque chose de nouveau s'est-il passé ? ». Demandez plutôt « quel est l'état actuel en ce moment ? ». Si vous regardez l'état actuel, les redémarrages n'ont plus d'importance.
Ne réinitialisez pas les horodatages pendant la récupération. Si vous réinitialisez une heure de « début » lors d'une tentative de réessai, vous effacez tous les faits survenus avant ce moment. Ne réinitialisez les horodatages que lorsque le travail réel change.
Surveillez l'endroit où les tâches s'accumulent, pas seulement si elles se terminent. Un décompte des tâches « terminées » vous indique que vous avez un problème. Une distribution des tâches par étape vous indique où se situe le problème. Nous avons trouvé le problème parce que nous avons vu 28 tâches bloquées à l'étape « en attente de révision ».
Un processus actif suivant une mauvaise règle n'apparaîtra jamais lors d'un contrôle de santé (health check). Il semble sain car il fonctionne exactement comme programmé.
Si vous construisez des systèmes automatisés, ne vous contentez pas de surveiller les erreurs. Surveillez l'endroit où vos processus s'accumulent.
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi