[Programmez!] Intelligence en essaim et industrie logicielle

L’intelligence en essaim

Nous nous enorgueillissons souvent, en tant qu’être humain, d’être particulièrement intelligent et capables de résoudre des problèmes complexes ! Cet orgueil est-il vraiment bien placé ? L’étude de comportement d’animaux « a priori » très peu intelligents nous montre que ces derniers arrivent néanmoins, de façon récurrente, à résoudre des problèmes pourtant très complexes !

Parmi ces « exploits » il y a notamment les fourmis qui sont capables très rapidement de toujours prendre le chemin le plus court entre leur fourmilière et la source de nourriture :

Source: wikipédia

De même, il y a les oiseaux et les poissons qui arrivent à voler ou nager de manière très concentrée sans pour autant entrer en collision.

Ces prouesses ne sont pas le fruit du hasard mais d’une « intelligence en essaim ». Les animaux ne voient pas le problème dans sa globalité mais obéissent à des règles simples tout en reposant sur un moyen de communication efficace. Pour les fourmis c’est suivre la piste avec la plus forte concentration de phéromones, pour les oiseaux c’est rester à une distance minimale des ses plus proches voisins !

On peut également penser aux « hola », aux retournements de pancartes dans les événements sportifs et aux chorégraphies complexes si on souhaite analyser des comportements humains.

De simples règles permettent donc d’accomplir des exploits. C’est en partant de cette observation, et plus précisément de l’exemple des fourmis, que « la robotique en essaim » est née.

La robotique en essaim

La robotique en essaim tente de proposer des solutions à des problèmes complexes, non pas en utilisant une intelligence artificielle complexe, mais en impliquant de nombreux robots dont l’intelligence est limitée (programmes avec des règles simples).

La robotique en essaim a vu le jour avec l’observation des fourmis. La résolution de la recherche du chemin le plus court a réussi à être résolu avec des robots en utilisant des traces lumineuses pour remplacer les phéromones :

Les recherches actuelles se concentrent plus sur les vols des oiseaux afin de faire voler des essaims de drones en évitant les accidents et en proposant une formation définie (il existe de nombreuses vidéos depuis 2018 à ce sujet). Les applications envisagées se font au niveau de l’exploration avec de la recherche de victimes après une catastrophe, la recherche de fruits malades pour une agriculture plus intelligente ou encore la détection de poussière pour nettoyer les appartements.

Les perspectives envisagées ne se limitent pas à de l’exploration mais aussi à la médecine avec, à l’horizon 2040 (cela reste une estimation), des robots en essaim utilisés pour détruire les cellules cancéreuses.

Bref, la robotique en essaim semble promise à un grand avenir mais, concrètement, à quoi cela peut ressembler actuellement ?

Un élément de réponse avec l’expérience menée par Mehdi Moussaid et partagée dans une vidéo de sa chaîne Youtube « fouloscopie » < https://www.youtube.com/channel/UCLXDNUOO3EQ80VmD9nQBHPg >.

Expérience de robotique en essaim

L’idée de l’expérience est de proposer un tournoi utilisant des robots ayant tous le même programme et devant s’acquitter d’une tâche le plus rapidement possible.

Les 12 robots doivent trouver une cible dans l’arène et « l’éliminer ». Cette tâche se déroule donc en 2 étapes

• L’exploration pour la découvrir la cible (vision et communication restreintes de chaque robot);
• La destruction où 2 actions sont possibles : attaquer ou prévenir les autres robots. La destruction est plus rapide si plus de robots attaquent.

Ce défi se fait avec les contraintes suivantes :

• Pour trouver la cible, un robot doit rouler dessus
• L’information sur la localisation peut être fournie uniquement par un robot qui connaît cette dernière
• Le rayon de communication des robots est limité

Enfin, « l’arène » de recherche et la position de départ du robot sont toujours les mêmes. Voici un schéma permettant de résumer le principe de cette expérience :

Le fonctionnement du tournoi est le même que celui des tournois de tennis en prenant le meilleur des 10 manches (11 si égalité) entre 2 algorithmes.

A noter : cette expérience est possible grâce au « robotarium » qui permet de programmer des robots à distance et de voir leur comportement. Le robotarium a été créé par Magnus Egerstedt. Il propose aux chercheurs du monde entier de prendre le contrôle de robots à distance pour conduire des expériences scientifiques. Le robotarium est accessible à des visiteurs qui souhaitent voir en direct le comportement des robots.

Algorithmes proposés

De nombreuses personnes ont participé à l’expérience. Au total, 64 algorithmes ont été proposés. Ces algorithmes peuvent être catégorisés en 3 familles (dont 2 principales représentant chacune environ 45 %) :

Centralisés

• Approche militaire : on décide à l’avance comment vont bouger les robots
• Très peu de marge d’improvisation, le programmeur est un chef d’orchestre

Distribués

• Directives simples et assez vagues (ex : rester à une certaine distance + déplacement libre)
• Pas de contrôle sur l’emplacement exact

« Hybrides »

• Globalement un mixte des 2 approches avec des résultats globaux qui sont en moyenne entre les 2 types d’algorithmes principaux

Cela donne cette répartition :

Résultats de l’expérience et analyse

Le résultat de ce tournoi donne une victoire avec une courte avance (6 à 5) pour un algorithme distribué. sur le meilleur algorithme centralisé. Néanmoins la 2^ème et la 3^ème place sont occupées par des algorithmes centralisés et la moyenne de destruction des cibles est largement en faveur des algorithmes centralisés qui mettent en moyenne 30 secondes de moins que les algorithmes distribués pour détruire la cible :

Ces résultats montrent qu’avec un contexte figé et connu il est généralement plus intéressant d’adopter une approche militaire, très cadrée.

Si l’on pousse l’expérience plus loin et que l’on décide de modifier 1 paramètre, la position de départ comme ci-dessous :

On remarque alors que la performance des algorithmes centralisés est très fortement dégradée contrairement à celle des algorithmes distribués :

Ce résultat semble logique car comme le dit Mehdi Moussaid dans sa vidéo :

« Quand on décentralise la prise de décision, le groupe peut s’adapter beaucoup plus facilement à un nouvel environnement parce que le chef n’a pas besoin d’intervenir à chaque fois pour repenser la stratégie et c’est probablement pour ça que ça marche aussi bien dans la nature »

Au-delà de cette « logique », il me semble intéressant de faire un parallèle avec les métiers de l’IT.

Cycle en V vs Agile

Le duel « Cycle en V vs Agile » est un duel qui est actuellement largement à l’avantage de l’Agile. Ce n’était pas le cas il y a encore 10 ans ! Au-delà de la théorie et du discours pro Agile (que je tiens également) sur la capacité à répondre au changement, s’adapter et livrer de la valeur plus vite, il me semble important d’analyser des raisons possibles de cette évolution grâce aux résultats présentés précédemment.

Pour rappel, dans l’expérience avec les robots, le modèle distribué avec peu de planification, des règles simples et une relative liberté des robots s’adapte en moyenne mieux au changement que le modèle centralisé (« militaire »).

Ce changement est tangible dans notre vie de tous les jours avec une évolution très rapide des demandes des utilisateurs, des technologies ou même des terminaux utilisant les logiciels c’est d’ailleurs un point très important remonté dans le framework SAFe < https://www.scaledagileframework.com/ >. Ce contexte semble favoriser les algorithmes dits « distribués » qui sont peu impactés par ces évolutions du contexte.

Si on analyse brièvement les caractéristiques du cycle en V et de l’Agile on peut arriver à ce tableau :

L’Agile semble donc être relativement proche d’un modèle distribué et le cycle en V d’un modèle centralisé.

Connaissant cela et le contexte actuel, il semble logique que l’Agile, plus performant dans notre monde moderne soit privilégié ! Le cycle en V reste néanmoins performant dans des situations maintenant minoritaires où l’on maîtrise l’environnement et que l’on n’a pas besoin de s’adapter à des changements fréquents.

Agile à l’échelle

La liberté est très importante afin de s’adapter. Néanmoins, la performance des algorithmes distribués avec cette liberté n’existe que s’il y a une collaboration de tous les instants avec des règles communes  même si elles restent simples !

Pour rappel, les robots en essaim avec un algorithme distribué proposent ces caractéristiques :

• Décentralisation partielle de la prise de décision
• Tous les robots ont le même programme « simple »
  • Simple mais permettant la collaboration
• Chaque élément ne voit pas le problème dans sa globalité

Il est alors très aisé de faire un rapprochement avec l’Agile à l’échelle (ou même dans une moindre mesure à des équipes agiles) :

L’Agile à l’échelle peut s’inspirer de bonnes pratiques des essaims: Les équipes doivent garder de l’indépendance mais aussi adopter un socle commun (communautés de pratiques, règles simples, outils…)Les équipes sont indépendantes mais doivent communiquer (synchronisation possible avec une équipe transverse)

Il est bon de noter que dans ce cas il faut savoir trouver le juste milieu entre des règles communes et l’indépendance de l’équipe, les 2 extrêmes étant néfastes (pas de règles = perte de temps et manque de synchronisation ; trop de règles = retomber dans les travers du « cycle en V »). Pour aller plus loin sur le sujet vous pouvez vous pencher sur le concept et Panarchie et de double-boucle d’apprentissage présentés dans le livre de Christophe Moustier.

Il n’est d’ailleurs pas étonnant que des modèles comme SAFe et Spotify accordent une part importante à ce socle commun ou lieu de partage. SAFe avec la « system team » et les communautés de pratiques,  Spotify avec les guildes et les tribus.

Les tests

Le parallèle peut également être fait avec le test :

Les robots en essaim, tout comme les tests, doivent s’adapter au contexte (dans l’expérience présentée, cela peut être le nombre de robots, la taille et la couleur de la cible, la disposition initiale ou encore la taille et forme de l’arène) Pour les robots en essaim, tout comme pour les tests, la qualité du résultat final dépend de tous. Pour les robots en essaim, tout comme pour les tests, personne ne peut tout faire ou tout savoir. Chacun fait sa part, communique et a sa vision, son point de vue.

Le test a d’ailleurs déjà développé des techniques permettant de répondre à ces difficultés. On peut par exemple citer :

• Les tests exploratoires

Afin de s’adapter au contexte et comme l’a montré l’expérience, il faut  avoir une décision au moins en partie décentralisée. Il ne faut pas tenter de tout prévoir en amont. Les tests exploratoires offrent une solution quasi parfaite à cette problématique en offrant une totale liberté au testeur dans un certain cadre défini par la charte de tests exploratoires (temps dédié, périmètre de test, persona…). Les tests exploratoires sont un parfait complément aux campagnes plus classiques en ce qu’ils offrent une grande flexibilité au testeur qui va pouvoir multiplier les tests et les adapter au fil de l’eau. Finalement, les tests exploratoires offrent un gain de temps très important tout en renforçant la qualité globale du logiciel… Et en luttant contre le paradoxe du pesticide.

Il n’est pas étonnant que ces tests soient considérés comme essentiels pour beaucoup de professionnels du test dont Frédéric Assante Di Capillo qui en a fait un article sur le blog de la taverne du testeus < https://latavernedutesteur.fr/2021/02/25/les-tests-exploratoires-une-obligation-dans-lagilite/ >.

Il me semble également bon de rappeler que les tests exploratoires dépendent fortement du testeur (ce dernier doit de préférence bien connaître le produit et être un minimum expérimenté) et qu’ils sont généralement moins adaptés pour les logiciels « critiques » ou fortement contraints (contexte légal ou autre). Dans ce cas là on peut penser à retourner sur une solution “centralisée” qui est meilleure “en moyenne” dans un contexte spécifique, connu et stable.

• Le modèle en tranches d’emmental

Le modèle en tranches d’emmental est plus une représentation qu’une vraie technique. Ce modèle est également applicable aux “niveaux de test” et ainsi expliquer leur raison d’être. Il permet néanmoins de montrer simplement qu’il n’existe pas de campagne unique permettant de détecter l’ensemble des anomalies. Une détection efficace des anomalies ne peut se faire qu’en multipliant les types de tests à différents niveaux. Chaque acteur du projet doit faire des tests à son niveau et œuvrer pour la qualité du logiciel. Sans ce travail de tous les instants et effectué par tous, la perte de qualité s’en fait grandement ressentir.

Cette complémentarité des tests et des acteurs est d’ailleurs régulièrement mise en avant dans les articles ayant pour sujet la qualité. Je pense notamment à l’article de Benjamin Butel « Développeurs et testeurs : équipe de choc <https://latavernedutesteur.fr/2020/01/14/developpeurs-et-testeurs-equipe-de-choc/ > » où une partie de la conclusion est :

« Développeurs + testeurs + bonne communication = produit qualité »

Vous noterez que la communication reste prépondérante… tout comme pour les robots en essaim.

• Le crowdtesting

Le crowdtesting est une pratique de test relativement récente (une dizaine d’années). Le principe, tout comme celui d’une bêta test, est de faire intervenir des utilisateurs potentiels pour tester un logiciel (ou une version), en général avant sa mise effective sur le marché. Là où le crowdtesting diffère d’une bêta c’est que les crowdtesteurs sont rémunérés et cadrés dans leur démarche de test ce qui est assez rare dans les bêtas. Leur but n’est pas forcément de simplement donner un avis ou juste utiliser le logiciel mais bien de le tester. On peut d’ailleurs pousser le parallèle avec la robotique en essaim en comparant chaque crowdtesteur à un robot de l’essaim. L’essaim de testeurs est « programmé » de manière assez faible, ce qui lui permet d’acquérir un certain niveau de liberté.

D’un point de vue technique, une mise en place d’une campagne de crowdtesting peut ressembler à cela :

Ces campagnes remontent des anomalies de différents types mais surtout des anomalies non trouvées par les équipes de développement (au sens large) et connaissant parfaitement leur logiciel.

Si vous voulez en savoir plus sur le Crowdtesting, je vous invite à regarder le Webinaire « L’expérience du Crowdtesting < https://www.youtube.com/watch?v=Fd8xt75J4nE& > » disponible sur la chaîne Youtube du blog de la taverne du testeur.

Pour résumer, le crowdtesting est peut se rapprocher du « test en essaim » en prenant en compte ces caractéristiques :

Conclusion

La phrase de Mehdi Moussaid (chercheur dans l’étude du comportement des foules (appelé fouloscopie) et créateur/animateur de la chaîne éponyme) :

« Quand on décentralise la prise de décision, le groupe peut s’adapter beaucoup plus facilement à un nouvel environnement parce que le chef n’a pas besoin d’intervenir à chaque fois pour repenser la stratégie et c’est probablement pour ça que ça marche aussi bien dans la nature »

me semble un très bon point de départ pour penser en terme d’essaim et plus généralement en terme d’efficacité dans de nombreux domaines ce qui inclut évidemment le logiciel. Dans cet article je ne propose que des pistes de réflexion à la suite des résultats d’une expérience. Il va sans dire que nous pouvons pousser la réflexion plus loin sur les domaines de l’Agile, de l’Agile à l’échelle, du test ou tout autre sujet de notre vie quotidienne.

S’il y a un point qui ressort selon moi de cette analyse de l’intelligence en essaim, c’est bien qu’il n’y a pas forcément besoin d’être un génie pour accomplir de grandes choses ! Il n’y a pas forcément besoin non plus d’avoir quelqu’un capable de tout prévoir (de toute manière, cela n’existe pas). Non, pour accomplir des exploits, il faut surtout un travail collaboratif, de la communication qui soit coordonnée par des règles communes simples et un objectif commun. Il est bon de noter que cela ne s’applique pas uniquement à l’homme mais aussi aux animaux ou encore les neurones d’un cerveau !

Au final, comme vous l’avez remarqué, par intelligence en essaim on peut également comprendre intelligence collective… On voit alors l’intérêt de travailler ensemble, de former une équipe afin d’arriver à atteindre nos objectifs. Cela transparaît particulièrement bien à travers ces phrases de Michael Jordan: 

« There are plenty of teams in every sport that have great players and never win titles. Most of the time, those players aren’t willing to sacrifice for the greater good of the team. The funny thing is, in the end, their unwillingness to sacrifice only makes individual goals more difficult to achieve. »

que l’on pourrait traduire par:

« Il y a beaucoup d’équipes dans tous les sports qui ont de grands joueurs et qui ne gagnent jamais de titres. La plupart du temps, ces joueurs ne sont pas prêts à se sacrifier pour le plus grand bien de l’équipe. Le plus drôle, c’est qu’au bout du compte, leur refus de se sacrifier ne fait que rendre les objectifs individuels plus difficiles à atteindre. « 

Un grand merci à Zoé Thivet, Benjamin Butel, Olivier Denoo, Christophe Moustier et Michael Granier pour leurs relectures et propositions d’améliorations pour cet articles qui… est aussi issu d’un travail collaboratif!