← Tous les articles

Des boids aux agents : les règles du vol groupé appliquées aux systèmes d'IA

En 1986, Craig Reynolds pose une question qui semble anodine : comment les oiseaux volent-ils en groupe ? Rien de philosophique là-dedans. Une question d’ingénierie. Il voulait produire des nuées convaincantes en images de synthèse sans scénariser la trajectoire de chaque oiseau.

L’algorithme des boids de Craig Reynolds (1986) démontre que trois règles locales simples — séparation, alignement, cohésion — engendrent un comportement global cohérent sans aucun contrôle centralisé, et les mêmes dynamiques gouvernent les systèmes d’IA multi-agents. Des agents qui suivent des consignes locales produisent une coordination émergente quand les règles sont bien choisies, et un chaos émergent quand elles ne le sont pas. Empiler les règles pour couvrir les cas limites dégrade les agents au lieu de les améliorer.

Sa réponse tenait en trois règles. Séparation : s’écarter pour ne pas s’agglutiner sur ses voisins. Alignement : s’orienter vers le cap moyen des voisins. Cohésion : se diriger vers la position moyenne des voisins. Aucun chef, aucun plan de vol, aucun contrôleur central. Trois règles appliquées localement par chaque oiseau, et il en sort une coordination globale impossible à distinguer d’un vrai vol groupé.1

Quarante ans plus tard, j’exploite un système d’IA multi-agents construit autour de dix rôles d’agents spécialisés qui enquêtent, débattent et votent sur des décisions. La nuit où un seul prompt a engendré 23 agents de façon dynamique — chacun en engendrant d’autres dans une cascade incontrôlée — et où tous ont atteint un consensus parfait sur la mauvaise question, j’ai compris que j’observais exactement les dynamiques décrites par Reynolds : une coordination émergente issue de règles simples, et une défaillance émergente issue du même mécanisme.

L’essentiel

L’algorithme des boids de Reynolds démontre que trois règles locales simples engendrent un comportement global cohérent sans contrôle centralisé. Des agents qui suivent des consignes locales (évaluer ce code, examiner cette surface de sécurité, passer cette architecture en revue) produisent une coordination émergente quand les règles sont bien choisies, et un chaos émergent quand elles ne le sont pas. Empiler les règles pour couvrir les cas limites rend les agents moins performants, pas plus. Mon emballement à 23 agents l’a prouvé : un budget d’engendrement qui contraint la largeur, et pas seulement la profondeur, est l’équivalent, côté agents, de la règle de séparation de Reynolds.


Trois règles, une infinité de nuées

Activez et désactivez les règles ci-dessus pour observer le résultat. Avec les trois règles actives, les boids volent naturellement en groupe. Retirez la séparation : ils s’effondrent en une masse unique. Retirez l’alignement : ils se dispersent en mouvements aléatoires. Retirez la cohésion : ils s’éloignent les uns des autres tout en conservant un cap local. Chaque règle est nécessaire. Aucune ne suffit à elle seule.

Reynolds a présenté ces travaux au SIGGRAPH 1987 sous le titre « Flocks, Herds, and Schools: A Distributed Behavioral Model ».1 L’article a changé l’image de synthèse. Avant les boids, animer une nuée exigeait des trajectoires écrites à la main. Après, les nuées émergeaient de règles. Plus d’une décennie plus tard, en 1998, Reynolds a reçu pour ces travaux le Scientific and Engineering Award de l’Academy of Motion Picture Arts and Sciences.2

L’apport profond ne tenait pas aux règles elles-mêmes. Il tenait à la démonstration qu’une coordination globale n’exige pas une connaissance globale. Chaque boid ne connaît que ses voisins immédiats. Aucun boid n’a de carte de la nuée. Aucun boid ne connaît la destination de la nuée. La nuée n’a pas de destination. Ce qui ressemble à un mouvement coordonné n’est qu’une somme de décisions locales qui dessine une figure globale.


Des pixels aux processus

La correspondance entre boids et agents d’IA n’a rien de métaphorique. Un article présenté à un atelier NeurIPS 2025, « Revisiting Boids for Emergent Intelligence via Multi-Agent Collaboration », applique explicitement les principes des boids aux systèmes multi-agents.3 Les auteurs y utilisent les règles de Reynolds comme consignes en langage naturel pour des agents évoluant dans un environnement collaboratif de construction d’outils : l’alignement et la séparation découlent des métadonnées d’outils des voisins, tandis que la cohésion injecte la synthèse globale du tour précédent.

Ma correspondance à moi est plus simple, et elle vient de la construction du système avant même la lecture de l’article :

Règle des boids Équivalent côté agents Ce qu’elle évite
Séparation Budget d’engendrement : limiter le nombre d’agents actifs par parent L’entassement d’agents sur le même sous-problème
Alignement Critères d’évaluation partagés : tous les agents appliquent la même exigence de preuve Des agents qui travaillent selon des définitions incompatibles de la qualité
Cohésion Protocole de consensus : les agents convergent vers les conclusions du groupe Des agents qui dérivent vers des digressions sans rapport

Le parallèle n’est pas parfait. Les règles des boids sont continues (s’orienter vers le cap moyen). Les règles des agents sont discrètes (engendrer au plus 12 enfants). Les boids évoluent dans un espace de coordonnées. Les agents évoluent dans un espace de problèmes. Mais l’intuition structurelle tient : des règles locales, appliquées indépendamment par chaque agent, produisent un comportement de groupe cohérent. Et les modes de défaillance sont les mêmes.


La nuit où 23 agents se sont entendus sur la mauvaise question

Février 2026. Je demande à mon agent d’« étudier une amélioration du système de répartition des hooks ». L’agent évalue sa propre confiance à 0,58, ce qui déclenche le système de délibération. Trois agents d’investigation sont engendrés. Chacun repère des sous-problèmes et engendre ses propres agents d’investigation. Qui en engendrent d’autres.

Sept minutes plus tard : 23 processus d’agents actifs. 4,80 $ de crédits API. Une consommation de tokens qui grimpe à 0,70 $ par minute.

Le garde-fou anti-récursion suivait la profondeur (un parent engendre un enfant, qui engendre un petit-enfant), mais pas la largeur (un parent engendre 12 enfants qui en engendrent chacun 12 de plus). La limite de profondeur, fixée à 3, ne s’est jamais déclenchée parce que les agents s’étalaient à l’horizontale. J’ai tué les processus à la main.

Tous les agents s’accordaient à dire que le système de répartition des hooks devait être amélioré. Tous proposaient des modifications sensées. Pas un seul n’a interrogé la pertinence du périmètre même de l’investigation.

Le résultat illustre ce qui arrive quand on dispose de la cohésion et de l’alignement, mais pas de la séparation. Les agents convergeaient vers la même conclusion (cohésion) et s’accordaient sur les mêmes critères d’évaluation (alignement). Mais rien ne les empêchait de s’entasser sur le même sous-problème. Dans le vocabulaire de Reynolds, 23 boids occupaient le même point de l’espace — précisément ce que la règle de séparation interdit.


Le budget d’engendrement comme règle de séparation

Le correctif a pris 20 minutes. Un budget d’engendrement qui compte le total d’enfants actifs par parent, plafonné à 12.4 Une contrainte de largeur, et pas seulement de profondeur.

L’implémentation est un compteur, pas une règle :

# Simplified spawn budget (actual implementation uses hooks)
active_children = count_active_agents(parent_id=self.id)
if active_children >= MAX_CHILDREN:  # MAX_CHILDREN = 12
    return "Budget exhausted. Synthesize existing findings instead."
# else: allow spawn

Le hook applique la règle de façon déterministe. L’agent ne peut pas se justifier face à un compteur comme il se justifie face à une consigne du type « essaie de ne pas engendrer trop d’agents ». Le compteur autorise ou bloque. Sans discussion, sans interprétation.

En langage boids, le budget d’engendrement est la règle de séparation : ne vous entassez pas sur vos voisins. En langage agents : ne mettez pas plus de N agents sur un sous-problème, parce que le (N+1)ᵉ agent ajoute du coût sans ajouter de point de vue. L’incident des 23 agents m’a appris que la séparation est la plus importante des trois règles. Sans elle, alignement et cohésion deviennent pathologiques : des agents qui convergent avec enthousiasme vers la même mauvaise réponse.

Les implémentations courantes de l’algorithme de Reynolds attribuent d’ailleurs à la force de séparation un poids 1,5 à 2 fois supérieur à celui de l’alignement ou de la cohésion, exactement pour cette raison — une convention documentée dans l’article de suivi de Reynolds lui-même, « Steering Behaviors for Autonomous Characters » (GDC 1999), où il traite de la combinaison de forces par priorité et note que l’évitement des collisions (la séparation) reçoit en général la priorité maximale.8 Dans mon système, ce sont les hooks qui font respecter le budget d’engendrement (déterministes, insensibles aux justifications de l’agent), tandis que les prompts et le contexte façonnent l’alignement et la cohésion (plus souples, négociables). La contrainte la plus dure reçoit l’application la plus stricte.


Pourquoi multiplier les règles dégrade les agents

Manipulez de nouveau les règles de la simulation ci-dessus. Imaginez maintenant une quatrième règle : « éviter le centre du canevas ». Une cinquième : « privilégier la moitié supérieure ». Une sixième : « faire demi-tour toutes les 100 images ».

Chaque règle est raisonnable prise isolément. Ensemble, elles détruisent la nuée. Les boids tremblent entre des forces concurrentes, incapables de satisfaire toutes les contraintes à la fois. Le vol groupé, si élégant, se dissout en bruit : chaque règle crée un vecteur de force, et quand six vecteurs tirent dans des directions différentes, le mouvement résultant est pratiquement aléatoire.

J’ai observé le même schéma dans l’orchestration d’agents. Les premières versions de mon système de délibération multipliaient les règles élaborées : profondeur minimale d’investigation, nombre obligatoire de citations, production imposée de contre-arguments, passes d’avocat du diable forcées. Chaque règle corrigeait un cas de défaillance précis. Ensemble, elles produisaient des agents qui dépensaient plus de tokens à satisfaire les règles qu’à résoudre les problèmes. Un exemple concret : la règle du « contre-argument obligatoire » imposait à chaque agent d’argumenter contre sa propre conclusion. La règle du « nombre minimal de citations » exigeait trois sources par affirmation. Quand un agent produisait un contre-argument sincère, la règle de citation le forçait à trouver trois sources appuyant la position contraire — ce qui étayait parfois mieux la mauvaise réponse que la bonne. Les deux règles se combinaient pour récompenser un esprit de contradiction bien sourcé au détriment d’une analyse juste.

La philosophie de l’ingénierie cumulative que j’ai documentée explique pourquoi cela se produit à l’échelle du système : chaque nouvelle règle interagit avec toutes les règles existantes, ce qui engendre une complexité combinatoire. Dix règles ne donnent pas dix contraintes. Elles donnent potentiellement 45 interactions deux à deux. Le comportement du système devient plus difficile à prévoir, plus difficile à déboguer, et plus enclin à produire des défaillances émergentes.

L’article original de Reynolds l’avait implicitement compris. Il présentait trois règles. Reynolds a exploré des comportements supplémentaires (évitement d’obstacles, poursuite d’objectif), mais il a gardé minimal le cœur du modèle de vol groupé. Ajouter une quatrième règle fondamentale aurait imposé de rééquilibrer les poids des quatre — un problème dont la difficulté croît de façon combinatoire à chaque ajout.

La leçon côté agents : partez du jeu de règles minimal qui produit le comportement recherché. N’ajoutez une règle que lorsque vous constatez une défaillance précise qu’aucune règle existante ne traite. Et quand vous en ajoutez une, vérifiez qu’elle n’interfère pas avec les autres.


La décentralisation comme architecture

L’absence de contrôleur central n’est pas une limite des boids. C’est l’architecture. La nuée se coordonne parce que nul oiseau n’a autorité sur les autres. Si l’un devenait le chef, le système deviendrait fragile — dépendant du jugement de cet oiseau, vulnérable à sa défaillance. Le schéma fait écho au principe de résilience distribuée que crée le vide structurel dans d’autres domaines.5

On retrouve le même schéma dans l’ensemble des systèmes d’IA multi-agents. AutoGen de Microsoft (v0.4+, 2025) coordonne les agents par des protocoles de conversation plutôt que par une orchestration centralisée : chaque agent décide quand prendre la parole en fonction de son contexte local, et le framework évite explicitement de désigner un agent « chef de file ».6 CrewAI (v0.28+, 2025) définit des rôles d’agents et des règles de transfert via son abstraction de « crew », sans accorder à un agent unique un pouvoir de passage en force sur les autres.7 Dans mon système de délibération, aucun agent n’a de droit de veto. Chacun évalue de son côté. Le protocole de consensus agrège les conclusions. Si un agent produit n’importe quoi, les autres le mettent en minorité. Un contrôle centralisé réintroduirait le point de défaillance unique que la coordination décentralisée élimine.


Quand les trois règles ont fonctionné : une réussite discrète

L’incident des 23 agents marque les esprits parce qu’il a échoué avec fracas. Les réussites sont plus discrètes, et bien plus nombreuses.

Une semaine après l’ajout du budget d’engendrement, j’ai demandé au système d’« évaluer si l’infrastructure de tests A/B du blog doit assigner les variantes côté serveur ou côté client ». Le système de délibération a engendré trois agents d’investigation. L’agent 1 a exploré les approches côté serveur (par cookie, par session). L’agent 2 a exploré les approches côté client (localStorage, paramètres d’URL). L’agent 3 a évalué les schémas hybrides. Chaque agent a travaillé de son côté (cohésion : convergence vers la même question d’évaluation). Chacun a appliqué les mêmes exigences de preuve (alignement : critères de qualité partagés). Le budget d’engendrement a empêché tout agent d’engendrer ses propres sous-agents pour cette tâche (séparation : pas d’entassement).

Les trois agents ont rendu leurs conclusions. L’agent 1 privilégiait l’assignation côté serveur pour la cohérence SEO. L’agent 2 penchait pour le côté client, plus simple à mettre en œuvre. L’agent 3 a identifié une approche hybride conforme aux schémas déjà présents dans le code. Le protocole de consensus a synthétisé le tout : assignation côté serveur pour le blog (là où le SEO compte), avec surcharge côté client pour les composants interactifs (là où JavaScript tourne déjà).

Toute la délibération a duré quatre minutes et coûté 1,40 $. Aucun agent n’a engendré de sous-agents. Aucun ne s’est rallié prématurément aux autres. Les recommandations étaient indépendantes et véritablement complémentaires. L’architecture à trois règles a produit exactement le comportement décrit par Reynolds : des décisions locales qui débouchent sur un résultat global coordonné.


Des schémas émergents dans d’autres domaines

Le schéma « règles simples, comportement émergent » n’est propre ni aux boids ni aux agents. Il apparaît partout où des décisions locales s’agrègent en structure globale :

Les codes de Hamming illustrent une forme voisine d’émergence. Placer stratégiquement les bits de parité aux positions correspondant aux puissances de 2 crée un système où la position de l’erreur émerge du XOR des positions de tous les bits à « 1 ». Aucun bit ne sait où se trouve l’erreur. Sa localisation émerge de la structure. Un bit de parité isolé ne vous apprend presque rien. Plusieurs bits de parité aux bonnes positions vous apprennent tout.

Le Jeu de la vie de Conway produit des planeurs, des oscillateurs et une capacité de calcul Turing-complète à partir de quatre règles appliquées à une grille. Ces règles sont plus simples que celles des boids (une cellule survit si elle a 2 ou 3 voisines, meurt sinon). La complexité qui en émerge est sans limite.

Dans chaque cas, le schéma est identique : des règles locales, aucun coordinateur central, un comportement global émergent. Et dans chaque cas, le même mode de défaillance s’applique : ajoutez trop de règles et le système passe d’une émergence élégante à une interférence chaotique.


À retenir

Pour les ingénieurs qui conçoivent des systèmes multi-agents :

  • Trois règles font une nuée. Quatre, peut-être pas. L’intuition de Reynolds, c’est que trois règles bien choisies suffisent à la coordination émergente. En ajouter une quatrième crée des interférences capables de détruire le comportement que les trois premières produisaient. Partez du jeu de règles minimal qui produit le comportement recherché.

  • La séparation est la règle la plus importante. Sans elle, alignement et cohésion deviennent pathologiques et les agents convergent vers la même mauvaise réponse. Le budget d’engendrement (contrainte de largeur) est le changement isolé le plus déterminant que j’aie apporté à mon système multi-agents.

Pour les architectes qui construisent des systèmes distribués :

  • L’absence de chef est l’architecture. Un contrôle centralisé crée un point de défaillance unique. La coordination décentralisée par règles locales résiste mieux. Concevez vos systèmes d’agents sans « agent chef de file », sauf raison précise d’en ajouter un.

  • Plus de règles, plus d’interactions. N règles produisent jusqu’à N(N-1)/2 interactions deux à deux. Le comportement devient plus difficile à prévoir à chaque ajout. N’ajoutez une règle que lorsque vous constatez une défaillance précise qu’aucune règle existante ne traite.

Exercice : cartographiez votre propre système. Schématisez votre système multi-agents actuel (ou celui que vous comptez construire). Pour chaque agent, repérez laquelle des trois règles de Reynolds il applique. Si la séparation manque, ajoutez un budget d’engendrement ou une limite de concurrence. Si l’alignement manque, définissez des critères d’évaluation partagés. Si la cohésion manque, ajoutez une étape de synthèse. Le schéma révèle le mode de défaillance auquel votre système est le plus exposé.


FAQ

Que sont les boids, et pourquoi comptent-ils pour la conception d’agents d’IA ?

Les boids sont des agents simulés (à l’origine des « bird-oid objects ») qui suivent trois règles locales : séparation (ne pas s’agglutiner sur ses voisins), alignement (s’orienter vers le cap moyen des voisins) et cohésion (se diriger vers la position moyenne des voisins). Craig Reynolds les a présentés au SIGGRAPH 1987. Ils comptent parce qu’ils ont prouvé qu’un comportement global complexe et coordonné peut émerger de règles locales simples sans le moindre contrôleur central — un principe qui s’applique directement aux systèmes d’IA multi-agents, à la robotique en essaim et au calcul distribué.

Comment les règles des boids s’appliquent-elles à l’orchestration d’agents d’IA ?

Chaque règle des boids correspond à une contrainte de conception côté agents. La séparation devient un budget d’engendrement (limiter le nombre d’agents travaillant sur le même sous-problème). L’alignement devient un jeu de critères d’évaluation partagés (tous les agents appliquent la même exigence de qualité). La cohésion devient un protocole de consensus (les agents convergent vers les conclusions du groupe). La correspondance est structurelle, pas métaphorique : les deux systèmes font émerger une coordination à partir de règles locales appliquées indépendamment par chaque agent.

Pourquoi multiplier les règles dégrade-t-il les systèmes d’IA multi-agents au lieu de les améliorer ?

Chaque nouvelle règle interagit avec toutes les règles existantes, ce qui engendre une complexité combinatoire. Dix règles produisent jusqu’à 45 interactions deux à deux. Les agents dépensent leurs tokens à satisfaire des contraintes de règles plutôt qu’à résoudre des problèmes. La même dynamique apparaît chez les boids : ajouter une quatrième règle (par exemple « éviter le centre ») oblige à rééquilibrer les trois d’origine, et l’élégance du vol groupé se dégrade souvent en tremblements, les agents tentant de satisfaire simultanément des forces concurrentes.

Quand faut-il préférer un contrôle centralisé à une coordination émergente ?

Optez pour le contrôle centralisé lorsque vous avez besoin de garanties strictes d’ordonnancement (étapes séquentielles d’un pipeline), lorsque les défaillances doivent être traitées de façon déterministe (transactions financières), ou lorsque le système exige une décision unique et faisant autorité plutôt qu’un consensus (résolution de conflits de fusion). Optez pour la coordination émergente lorsque les agents peuvent évaluer de façon indépendante, lorsque la redondance améliore la fiabilité, et lorsqu’aucun agent n’a besoin de la vue d’ensemble pour bien faire son travail.


Cet article fait partie de la série Explorations interactives, où les algorithmes rencontrent l’intuition visuelle : des codes de Hamming qui détectent leurs propres erreurs aux boids qui volent en groupe sans chef. Les schémas d’orchestration d’agents sont détaillés dans Le système Ralph et La délibération multi-agents. La couche de programmation métacognitive ajoute à chaque agent une capacité d’auto-observation qui complète la coordination inter-agents évoquée ci-dessus.



  1. Reynolds, C. W. (1987). “Flocks, Herds, and Schools: A Distributed Behavioral Model.” SIGGRAPH ‘87: Proceedings of the 14th annual conference on Computer graphics and interactive techniques, pp. 25-34. red3d.com/cwr/boids/ 

  2. Reynolds a reçu le Scientific and Engineering Award de l’Academy of Motion Picture Arts and Sciences en 1998 pour ses contributions à l’animation comportementale, dans le prolongement des travaux sur les boids. L’algorithme est utilisé en production cinématographique depuis Batman : Le Défi (1992). oscars.org/sci-tech/ceremonies/1998. Voir également le CV de Reynolds : red3d.com/cwr/resume.html

  3. “Revisiting Boids for Emergent Intelligence via Multi-Agent Collaboration.” NeurIPS 2025 Workshop: Scaling Environment. openreview.net/pdf?id=46LJ81Yqm2. L’article applique les règles des boids comme consignes en langage naturel à des agents suivant une boucle observer-réfléchir-construire. 

  4. L’implémentation du budget d’engendrement est documentée dans Le système Ralph. La décision d’architecture décisive : faire respecter les limites de largeur par des hooks (déterministes) plutôt que par des prompts (indicatifs). Un agent à qui l’on demande de « limiter l’engendrement » trouvera toujours une justification pour dépasser la limite. Un hook qui compte les enfants actifs et bloque l’appel API d’engendrement, non. 

  5. Lao Tseu, Tao Te King, chapitre 11. Traduction : D.C. Lau, Penguin Classics, 1963. Le passage complet évoque le moyeu d’une roue, les murs d’une pièce et l’argile d’un vase : trois exemples où l’utilité vient du vide, non de la matière. Voir Le vide est structurel pour l’exploration complète. 

  6. Microsoft AutoGen, github.com/microsoft/autogen. AutoGen v0.4 (sorti en 2025) a introduit l’abstraction GroupChat, où les agents participent à des conversations sans chef désigné. La documentation du framework l’affirme explicitement : « AutoGen enables a group of agents to collectively perform tasks that a single agent alone cannot. » C’est le protocole de conversation, et non un contrôleur central, qui détermine l’ordre de parole. 

  7. CrewAI, github.com/crewAIInc/crewAI. CrewAI v0.28+ (2025) définit des « crews » composées d’agents par rôle et de règles de transfert des tâches. Le paramètre process accepte les modes “sequential” (ordre fixe) et “hierarchical” (délégation par un manager), mais même en mode hiérarchique, l’agent manager coordonne sans passer en force : il ne peut pas modifier la production d’un autre agent, seulement en demander la révision. Documentation : docs.crewai.com

  8. Reynolds, C. W. (1999). “Steering Behaviors for Autonomous Characters.” Game Developers Conference 1999 Proceedings, pp. 763-782. red3d.com/cwr/steer/. Reynolds y traite de la combinaison hiérarchisée des forces, où la séparation (évitement des collisions) est traitée en premier et consomme la force de pilotage disponible avant l’application de l’alignement ou de la cohésion. Ce schéma de priorité garantit que l’évitement de l’entassement prime toujours. 

Articles connexes

Codes de Hamming : comment les ordinateurs corrigent leurs propres erreurs

De la RAM aux QR codes : une exploration interactive de la détection et correction d’erreurs par les codes de Hamming.

9 min de lecture

GLSL pour les builders : un labo shader vraiment utilisable

Un playground GLSL pratique pour développer vite votre intuition shader : presets, contrôles live et WebGL sans framewor…

4 min de lecture

Le pattern Protégé

Un modele 7B avec acces expert sparse egale des agents 50x plus grands. Travail routinier aux petits modeles, jugements …

9 min de lecture