Supprimez le comptage des pairs : 7 colonies sur 8 se sont rétablies, contre 0

Le mécanisme qui semblait essentiel était celui qui faisait les dégâts

Un simulateur de colonie de fourmis appelé ant-sim, écrit en 2021 puis remanié en 2026, a été soumis cette année à une série d'ablations : huit mondes générés, la moitié des butineuses éliminée à la minute 50, un seul mécanisme retiré à la fois. L'ensemble complet des règles s'est rétabli après ce choc dans 0 monde sur 8. Si l'on retire l'estimation de l'affluence (l'estimation que fait chaque fourmi du nombre de ses semblables déjà affectées à une tâche), 7 mondes sur 8 se rétablissent, en 6,1 minutes. Le temps passé en sous-service de la quête de nourriture passe de 76 % à 22 %. L'erreur de suivi s'améliore elle aussi.

L'auteur publie le commit (d430093), la commande qui reproduit le tableau et les sorties brutes, et il est explicite sur la portée : ce sont des fourmis simulées, pas un benchmark d'agents, et les implications pour les systèmes d'IA sont des propositions, pas des résultats. Une version antérieure de la comparaison comportait un biais de confusion relevé par un relecteur : la ligne « tableau seul » retirait discrètement deux mécanismes à la fois. Le tableau corrigé les sépare.

Comment la colonie répartit réellement le travail

Il n'y a pas de répartiteur central. Chaque fourmi lit un tableau public des besoins : pour chaque tâche, la quantité de travail demandée et la quantité récemment livrée. Elle combine cela avec sa propre estimation de l'affluence sur chaque tâche, fondée sur les ouvrières qu'elle a croisées, compare son travail actuel à l'alternative la plus pressante, et peut changer de tâche. Achever un travail modifie le tableau : la nourriture rapportée crée un besoin de stockage, le couvain crée un besoin de soins. Le comportement de la colonie est la somme de ces décisions individuelles et des couplages entre tâches.

Le tableau est l'élément porteur. Sans lui, la quête de nourriture est sous-servie 100 % du temps dans toutes les exécutions, et trois mondes sur huit meurent de faim. Les seuils de réponse individuels, c'est-à-dire l'idée que la variation entre ouvrières amortit les oscillations, n'ont presque rien changé aux mesures. L'auteur avait une histoire pour expliquer leur importance ; les exécutions ne l'ont pas confirmée.

Pourquoi compter ses pairs donne un mauvais chiffre

L'estimation de l'affluence échoue pour une raison qui se transpose directement aux logiciels. Les fourmis mesurent les effectifs d'après les congénères qu'elles rencontrent, et ce qu'on rencontre dépend de l'endroit où l'on travaille. Les tâches concentrées en un point paraissaient trois à cinq fois plus pourvues en personnel qu'elles ne l'étaient : 4,7 fois pour les soins à la reine, 4,4 pour le creusement, 3,9 pour le stockage, 3,6 pour les soins au couvain. Le travail réparti sur le territoire paraissait sous-doté : 0,49 pour l'exploration, 0,66 pour la quête de nourriture. L'erreur d'échantillonnage existe avant même qu'une fourmi ne décide quoi que ce soit.

Déplacer le comptage à l'entrée du nid a divisé par deux les changements de tâche et évité deux cas de famine, mais n'a presque pas touché au biais. Une entrée échantillonne le trafic, pas les effectifs. Une nourrice qui travaille près du puits le traverse constamment ; une butineuse ne fait qu'un long trajet. Les tâches à trajets courts sont surcomptées d'un facteur d'environ quatre.

Deux bugs à s'approprier

Le tableau divisait à l'origine le besoin cumulé sur toute la durée de vie par le travail livré cumulé. Au début d'une exécution, un pic faisait varier le ratio de 17 % ; trois heures plus tard, le même pic le faisait varier de 0,003 %. Rien n'échouait de façon visible : la colonie devenait simplement sourde. Faire décroître les deux totaux avec une demi-vie a rétabli la situation. L'arriéré dit ce qui demande de l'attention ; le compte cumulé des éléments traités, non.

La seconde classe de bugs : des signaux générés à partir d'un stock plutôt que d'un travail inachevé. Le besoin de stockage évoluait avec tout ce que contenait le grenier, si bien que la nourriture déjà stockée continuait à exiger du stockage. Doubler la nourriture disponible produisait des colonies plus petites (population moyenne de 180 contre 206), car les ouvrières s'entassaient dans le stockage et le creusement pendant que le couvain mourait. Le creusement avait la même forme : une colonie à la génération 23 comptait 140 fourmis, 93 % de son territoire excavé, quarante salles presque vides, 25 creuseuses et 8 nourrices pour 58 larves. Lier le creusement à l'affluence réelle a réduit la taille du nid au tiers et le nombre de creuseuses au quart, sans perte de population. Le test que l'auteur propose pour chaque signal : quelle chose inachevée ce signal mesure-t-il, et quelle action accomplie le fait-elle disparaître ?

Un dernier point, sur l'attribution du crédit. Les butineuses revenues les mains vides comptaient autant que celles qui rapportaient de la nourriture, si bien que le tableau signalait la collecte comme assurée alors que rien n'arrivait. Ne compter les retours que lorsque de la nourriture est effectivement rapportée a laissé six colonies sur huit plus grandes et augmenté l'apport alimentaire à chaque saison. La réserve compte plus que le résultat : une charge de nourriture est vérifiable. Pour les autres tâches, atteindre le lieu de travail compte comme du travail, et le modèle ne peut pas distinguer un bon résultat d'un mauvais. Un agent qui écrit du code a besoin d'une vérification de correction indépendante ; revenir n'est pas la preuve d'un succès.

Les questions à vous poser

• Votre couche d'orchestration estime-t-elle combien d'agents travaillent sur une tâche, et avez-vous comparé cette estimation au nombre réel, ou bien échantillonne-t-elle du trafic, comme la version qui comptait à l'entrée ?
• Parmi vos métriques de routage, lesquelles sont des totaux cumulés sur la durée de vie ? Faites le test : de combien un pic soudain déplace-t-il le chiffre à la première heure, puis à la troisième ?
• Pour chaque signal de file d'attente sur lequel vous agissez : quelle action accomplie le ramène à zéro ? S'il n'y en a aucune, vous payez des agents pour refaire un travail déjà terminé.
• Savez-vous distinguer l'exécution réussie d'un agent de celle qui s'est simplement terminée, ou « il est revenu » est-il votre définition de « terminé » ?
• Quelqu'un a-t-il comparé cette approche décentralisée à un simple répartiteur sur votre charge de travail, en chiffrant les échéances et le coût du changement d'agent ? L'auteur, lui, ne l'a explicitement pas fait.

Ce qu'il faut surveiller ensuite

La ligne que personne ne devrait ignorer est la dernière : sans l'estimation de l'affluence ni le filtre d'échantillon, 73 fourmis se sont ruées vers la quête de nourriture après le choc, soit quatre fois le troupeau observé avec la règle complète, et les huit colonies se sont rétablies en 1,5 minute, la plus rapide de toutes les configurations. Le comportement de troupeau n'était pas un problème, car il allait dans la bonne direction. Surveillez ceux qui porteront ce mécanisme dans un vrai pool d'agents et rapporteront ce qui se passe quand le troupeau va dans la mauvaise direction, et la question de savoir si un tableau de demande à décroissance, à lui seul, bat un répartiteur en coût et en latence. Tant que personne ne publiera cette comparaison, il s'agit d'une hypothèse bien instrumentée, pas d'une architecture.