Les vertus de l'émergence

Les vertus de l’émergence – Christophe Addinquy

1 / 18

Les vertus de l’émergence

Par Christophe Addinquy

Il y a quelque temps, j’ai échangé avec le CFTL (Comité Français des tests logiciels) à propos d’un article publié sur leur site concernant TDD1. Un article fondamentalement mal informé, peut-être même malhonnête et sans aucun doute rédigé par une personne incompétente sur la question. J’avais donc répondu à cet article2. Une réponse assez longue il faut bien le dire, à l’image du nombre d’inepties que j’y relevais. L’une d’entre-elles a attiré mon attention. « Comment la refactorisation répétée, un processus exclusivement de bas en haut, produit-‐elle une conception élégante ? Ceci est une affirmation très controversée, supportée par bien peu de preuve…

… Rien dans TDD ne traite directement des aspects de performances. Une possibilité serait que ce soit pris en compte lors de la refactorisation » Paul C. Jorgensen, Ph.D., Professor School of Computing and Information System, Grand Valley State University, Allendale, MI

Ainsi donc, Mr Jorgensen ne croit pas à la conception émergente, car c’est bien de cela que nous parlons.

Je ne vais pas m’attarder sur la question de l’élégance du design émergent aujourd’hui. Il m’est pourtant facile d’évoquer la conception des frameworks logiciels conçus de manière itérative et émergente par nature3 4 5 pour balayer d’un revers de main le « bien peu de preuve » asséné de manière péremptoire par Mr Jorgensen.

Nous allons plutôt concentrer notre attention sur la question de la performance. Celle-ci peut-être mise en évidence par la question de la scalabilité. Aussi pour répondre à Mr Jorgensen, pouvons-nous chercher à répondre à la question suivante :

1 Test-Driven Development : un pacte diabolique ? Accessible sur le site du CFTL : http://www.cftl.fr/index.php?id=78 2 Réponse à Test-Driven Development : un pacte diabolique ? Accessible sur mon blog Tumblr : http://addinquy.tumblr.com/post/15037040242/reponse-a-test-driven-development-un-pacte 3 Building Application Frameworks ; Mohamed E. Fayad, Douglas C. Schmidt & Ralph E. Johnson edt. ; John Wiley & sons 1999 ; ISBN 0471248754 4 Implementation Patterns ; Kent Beck ; Addison Wesley / Signature series 2007 ; ISBN 9780321413093 – p. 117 5 Extreme Programming Explained, 2nd édition ; Kent Beck & Cynthia Andres ; Addison Wesley / XP series 2004 ; ISBN 9780321278654 – p . 52


2 / 18

Est-il possible de faire état d’architecture ayant évolué de manière émergente, ayant commencé petit pour arriver à un niveau de performance et de charge beaucoup plus important qu’initialement ?

Bien sûr pour que ces exemples (car nous allons en voir plusieurs) soient recevables, il faut que ce « beaucoup plus important » soit significatif. De manière à ne pas être réfutable, nous allons parler de facteurs de magnitude importants. Très importants. Et prendre des exemples de grande ampleur. De très grande ampleur. Pensez à quelque chose de très grand, multipliez-le disons par dix : nous terminerons notre voyage avec un exemple plus grand encore que cela.

Facebook ! L’IPO6 de Facebook nous a familiarisé avec nombre de chiffres faramineux. Nous pourrions certainement les aligner à l’envi, mais je vais me limiter à deux d’entre eux :

• Le trafic sur Facebook aujourd’hui est équivalent à celui de la totalité de l’Internet en 2004.

• En 2010, le nombre de serveurs estimés pour faire fonctionner le n°1 des réseaux sociaux était de 600007 ! On peut imaginer que ce chiffre ait doublé aujourd’hui.

Pourtant nous sommes plus ou moins familiers de l’histoire du site : il a simplement débuté sous la forme d’un site classiquement développé en PHP, écrit par une seule personne en quelques semaines8. A aucun moment, lors de ce stade initial, Mark Zuckerberg n’avait prévu ou anticipé une telle montée en charge.

Justement, qu’en est-il de l’architecture de Facebook aujourd’hui ?

Curieusement, cette architecture s’appuie encore sur du PHP9 10, mais il s’appuie sur un compilateur (HipHop) convertissant ce code en C++. Des couches applicatives sont dédiées à l’accélération de performance en aval : BigPipe pour accélérer le rendu ou Varnish comme proxy HTTP.

Côté back-end on trouve Memcached, MySQL monté en cluster mais aussi Hadoop comme brique de base de la partie décisionnel ou Haystack, une technologie de stockage optimisé pour stocker les plus de 100 milliards de photos archivées par les 800 millions d’utilisateurs du site.

6 Initial Public Offering, processus de mise sur le marché des actions de sociétés non encore cotées en bourse avec évaluation de celles-ci : http://www.investopedia.com/terms/i/ipo.asp 7 http://downloadsquad.switched.com/2010/06/29/facebook-doubles-its-server-count-from-30-000-to-60-000-in-just-6-months/ 8 http://en.wikipedia.org/wiki/Facebook 9 Voir l’excellente synthèse architecturale de Michaël Figuière sur Quora : http://www.quora.com/What-is-Facebooks-architecture 10 http://www.makeuseof.com/tag/facebook-work-nuts-bolts-technology-explained/


3 / 18

Finalement, Facebook a même construit sa propre architecture matérielle pour ses serveurs11 !

En lisant la longue liste des briques logicielles constituant Facebook, il faut garder ceci à l’esprit : cette architecture n’a pas été définie ni au départ, ni à un moment donné ultérieurement. Chaque pièce a été introduite, l’une après l’autre, pour adresser un problème de performance ou de montée en charge à un moment donné. En fait certaines briques introduites ont même disparu aujourd’hui, comme c’est le cas de Cassandra12.

L’architecture telle qu’elle existe actuellement est une œuvre purement émergente. Elle n’a pas fini d’évoluer, de se transformer. Demain elle sera encore différente.

Exemple n°2 Peut-on imaginer un service qui fasse ses débuts depuis un ordinateur portable ?

Figure 1 : Une architecture de déploiement vraiment minimaliste !

Certainement, me répondrez-vous, mais pas un service sérieux ou en tout cas destiné à prendre de l’ampleur !

Je n’ai hélas pas trouvé de photo du portable que je voulais. J’ai pris toutefois celle d’un modèle équivalent. La machine que j’évoque appartenait à cette personne :

11 http://www.zdnet.com/blog/btl/facebook-open-sources-its-server-data-center-designs-hardware-fallout-to-follow/47045 12 http://facility9.com/2010/11/facebook-messaging-hbase-comes-of-age/


4 / 18

Figure 2 : L'architecte initial de Tweeter

Sur le profil Twitter de Noah Glass vous pouvez lire « I started this ». La première version de Twitter fonctionnait effectivement sur son ordinateur portable13 !

Parler chiffre pour Twitter est moins saisissant que pour Facebook … mais cela reste plus que conséquent : 340 millions de messages par jour en moyenne14, 7000 Tweets par seconde en pointe. N’oublions toutefois pas que la diffusion des Tweets fonctionne sur la base d’abonnements. Cela prête peu à conséquence quand on s’appelle Christophe Addinquy…

Figure 3 : Le profil Twitter de votre serviteur

Mais quand on s’appelle Lady Gaga, il en va tout autrement…

Figure 4 : Le record de followers de Twitter

D’un point de vue de l’architecture, deux points principaux sont à noter :

13 http://articles.businessinsider.com/2011-04-13/tech/29957143_1_jack-dorsey-twitter-podcasting 14 http://en.wikipedia.org/wiki/Twitter


5 / 18

Techniquement, on est passé d’une application Ruby On Rails à une architecture Java15, mais surtout Scala. Ruby reste présent pour la partie Web, mais le trafic via l’IHM Web représente aujourd’hui moins de 10% du total, le reste étant véhiculé via les APIs. On retrouve par ailleurs certaines solutions communes avec Facebook, comme Varnish et Memcached16 par exemple.

L’aspects qui me semble le plus notable est le changement de paradigme opéré par Twitter : le service a été pensé au départ comme une gestion de contenu, et la pile applicative RoR était pensée en ce sens. Bien qu’il soit toujours appelé par les médias « service de micro-blogging » il n’est plus considéré comme tel par ses architectes techniques depuis plusieurs années, mais perçu et pensé comme un système de messaging / broadcasting. Avec à la clé deux conséquences :

• Tout d’abord le développement d’un broker de messages, d’abord développé en Ruby, puis ré-écrit en Scala17.

• Une architecture fonctionnant en mémoire, les cluster de bases de données MySQL étant alors une persistance différée du contenu publié sur le service.

Depuis le service écrit en Ruby fonctionnant sur un portable, jusqu’au broker de message clusterisé développé en Scala, le chemin est non seulement long mais il a changé d’orientation au passage ! On est loin de l’approche « top-down » !

Exemple n°3 Cet exemple est aujourd’hui tellement célèbre qu’il ne nécessite pas de développement de ma part : il parle de lui-même.

C’est certainement plus conséquent qu’un Twitter fonctionnant sur un ordinateur portable. Mais même s’il est très difficile d’avoir des chiffres sur l’infrastructure de Google (on parle en centaines de milliers de serveurs), le service a bel et bien débuté avec ceci18 :

15 http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster 16 http://www.infoq.com/news/2009/06/Twitter-Architecture 17 Kestrel est le message broker de Twitter, écrit en Scala 18 http://royal.pingdom.com/2009/03/02/original-google-setup-at-stanford-university/


6 / 18

Figure 5 : Déploiement initial du Google Search Engine

Exemple n°4 Ceux qui ont connu le paysage de la fin des années 80 se souviennent peut-être de cette machine ?

Figure 6 : Un "NeXT", ou ce qu'il en reste, mais un exemplaire historique !

Il s’agit d’un NeXT, une magnifique (et coûteuse) machine19 créé par l’entreprise de Steve Jobs à l’époque où il fut écarté d’Apple. Mais ce n’est pas la machine en soi

19 http://simson.net/ref/NeXT/brochure_index.htm


7 / 18

qui nous intéresse, simplement celle figurant sur cette photo, elle appartient à un Anglais dont le nom figure sur le boitier.

Cette machine a en effet servi à faire fonctionner la version initiale de l’architecture documentaire répartie qu’il avait alors imaginé. Ce fut une réussite, celle-ci vient de fêter ses 20 ans en Août 201120. On dit que son créateur a retenu un nom dont la vertu principale était d’être imprononçable en Français (l’une des langues officielles du CERN) : World Wide Web.

Il est complètement inutile de souligner l’ampleur qu’a pris le Web depuis. Quand aux chiffres de montée en échelle dont nous parlions au début de l’article…

Je voudrais à la place faire le parallèle avec un architecture imaginée dès le début des années 1960 et développée pendant près de 40 ans par Ted Nelson. Celui-ci a imaginé, conceptualisé et développé un système dont les visées étaient celles du Web d’aujourd’hui (ou un sous-ensemble de ce qu’est le Web aujourd’hui, devrais-je dire). Ce projet s’appelait Xanadu21 22. Ce projet était innovant, brillant, novateur et visionnaire, et ses contributeurs ne l’étaient pas moins. En fait certaines des idées (l’hypertexte, notamment) ont inspiré Tim Berners-Lee. Entre autre choses, les concepts développées par l’équipe Xanadu englobaient des gestion de liens bidirectionnels, la gestion des auteurs des documents, du micro-paiement, de l’indexation et de la recherche sémantique. Ce magnifique projet fut aussi un échec total. Une somme considérable de temps, d’efforts et de compétences ne permettent simplement pas de venir à bout d’un projet d’ampleur mondial et d’ambition si élevée avec une approche « top-down ».

Le système initialement développé par Tim Berners-Lee avec l’aide de Robert Cailliau a duré 2 ans23. Le premier prototype a même été développé en quelques mois et intégrait déjà les briques de base de ce qui font du Web ce qu’il est aujourd’hui : HTTP et HTML. D’un point de vue technologique il était incontestablement moins élaboré que Xanadu et n’en couvrait fonctionnellement qu’une petite partie. Au début, il ne s’agissait que de permettre l’affichage et la navigation sur des sites purement statiques, à commencer par celui-ci24.

20 http://www.wired.com/geekdad/2011/08/world-wide-web-20-years/ 21 http://dubinko.info/blog/2009/11/22/how-xanadu-works/ 22 http://www2.iath.virginia.edu/elab//hfl0155.html 23 http://en.wikipedia.org/wiki/History_of_the_World_Wide_Web 24 Le groupe « Les Horribles Cernettes » ont fourni la première image cliquable du Web : http://fr.wikipedia.org/wiki/Les_Horribles_Cernettes


8 / 18

Figure 7 : La première image publiée sur le Web

Quels facteurs ont permis au Web de dépasser Xanadu en quelques années seulement ? Le facteur déclencheur tient en deux mots : open-source ! Le créateur du Web a dès le départ versé sa création dans le monde open-source. Sur cette base, le NCSA a développé le browser Mosaic25 qui deviendra Netscape. D’autres prendront le relai. Tout cela appartient aujourd’hui à l’Histoire. D’une seule personne, le développement du Web est passé à des dizaine, puis des milliers pour compter aujourd’hui des millions de contributeurs. Comment une approche subordonnée à une conception centralisée pourrait envisager de rivaliser avec cela ?

Ici l’émergence se décline sur les plans architecturaux, technologiques et humains.

Il est temps de prendre un peu de recul et d’analyser ce que ces quatre exemples marquants ont en commun.

Commencer petit Tous les projets que nous avons passé en revue ont ceci en commun : ils ont commencé petit. Ils n’ont pas cherché à extrapoler sur l’avenir, mais ont fait le choix d’être opérationnels le plus tôt possible, sur la base de ce qui était connu et maitrisé à ce moment là, d’un point de vue technologique come d’un point de vue business. Cette approche en rappelle une autre : celle du Lean Startup26.

25 http://www.ncsa.illinois.edu/Projects/mosaic.html 26 The Lean Startup ; Eric Ries ; Crown Business 2011 ; ISBN 9780307887917


9 / 18

Figure 8 : The Lean Startup, par Eric Ries

L’un des cinq principes du Lean Startup est la boucle « build – mesure – learn » avec une volonté claire de raccourcir autant que faire se peut cette boucle de feedback. Le Lean Startup considère que le business model est le produit. Plutôt que faire des plan basés sur des conjectures, on met à l’épreuve une première ébauche du produit, le MVP. Selon la réponse du marché à cette offre, on valide ou non les hypothèses et décide sur la base de ce feedback s’il faut persévérer ou s’il est préférable de « pivoter ».

Le second avantage de cette approche émergente est qu’elle permet d’occuper tôt les niches de marché car comme le souligne Geoffrey Moore « le marché donne une prime à celui qui est le premier »27.

La question de la boucle de feedback nous rapproche aussi de notre sujet initial : l’agilité. Nous venons de voir que feedback et émergence sont des principes connexes, deux aspects complémentaires d’un même mécanisme. Mais qu’est-ce qui lie l’émergence à l’agilité ? Est-ce une propriété intrinsèque des projets agiles ? Pour répondre à cette question, nous allons voir quel est la part prise par cette boucle de feedback dans le fonctionnement des projets agiles.

La boucle de feedback de l’agilité Je ne vais pas faire durer le suspens bien longtemps : Boucle de feedback et agilité sont des sujets intimement liés. En fait, cette boucle de feedback se retrouve à différente échelles et sous différentes natures. On peut même ramener les principales activités des projets agiles sous la forme de boucles de feedback.

27 Crossing the Chasm ; Geoffrey A. Moore ; Harper Collins 2001 ; ISBN 060087188


10 / 18

Figure 9 : Les boucles de feedback imbriquées de Scrum

De la seconde jusqu’au projet, le projet agile put être vu comme un ensemble de boucles « feedback –adaptation – émergence » :

• Quelques secondes : le feedback de la compilation incrémentale. Les environnements de développement modernes nous aident à ajuster notre code pendant que nous l’écrivons en soulignant les erreurs de syntaxe et de compilation. Nous rectifions notre code avant même d’exécuter les tests, nous épargnant ainsi du « bruit » inutile à ce moment-là.

• Une à quelques minutes : le feedback du TDD. Le cycle « red – green – refactor »28 nous donne du feedback à la fois sur le bon comportement du code et sur la qualité du design, nous permettant d’améliorer celui-ci sur la base de l’observation plutôt qu’en se conformant à un plan initial.

• Une à quelques dizaines de minutes : le feedback d’intégration continue29. A ce niveau d’échelle supérieur la boucle de feedback nous informe sur la façon dont le code que nous venons d’écrire se marrie avec la base de code existante.

28 Test-Driven Development by example ; Kent Beck ; Addison Wesley / Signature series 2003 ; ISBN 9780321246533 – p. 11 29 Continuous Integration ; Paul M. Duvall, Steve Matyas & Andrew Glover ; Addison Wesley / Signature series 2007 ; ISBN 9780321336385 – pp. 20, 37


11 / 18

• Continuellement dans la journée : le feedback de la revue de code en continu. Le pair programming joue ce rôle, donnant un regard extérieur au code produit30.

• Chaque jour : le daily meeting. La pratique du point journalier est un feedback de chaque membre de l’équipe vers les autres, permettant l’ajustement du plan d’action pour la journée31.

• Régulièrement au cours de l’itération : le feedback du PO sur les stories implémentées. En cours d’itération, l’équipe travaille avec le PO32 afin de faire converger le travail réalisé avec sa vision, mais parfois aussi de remettre en cause celle-ci !

• A la fin de chaque itération : le feedback sur ce qui a été réalisé lors de la démo. La démonstration sert de feedback sur la réalisation de l’itération33, en mettant en perspective ce qui a été réalisé par rapport à ce qui était planifié.

• A la fin de chaque itération : le feedback sur la façon dont nous avons travaillé lors de la rétrospective34 35. Il s’agit également d’une boucle de feedback mais au niveau des pratiques, de l’efficacité et du moral de l’équipe.

Nous aurions pu faire figurer d’autres boucles de feedback sur ce diagramme, mais cela l’aurait surchargé plus que de raison. On pourra par exemple évoquer :

• La boucle de feedback de la mise en production. Le « continuous delivery »36 promu surtout par le mouvement devops37 est une boucle de feedback sur le comportement de l’applicatif en conditions opérationnelles.

• La boucle de feedback des tests d’acceptance.

Nous venons de voir que l’émergence fonctionne au niveau des architectures logicielles, mais que ce principe s’étend également au développement agile et aux stratégies business. Mais ce champs d’application peut-il réellement s’étendre à plus grande échelle au sein des sociétés humaines ?

30 Pair Programming Illuminated ; Laurie Williams & Robert Kessler ; Addison Wesley 2003 ; ISBN 0201745763 – p. 27 31 Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition ; Claude Aubry ; Dunod 2011 ; ISBN 9782100563203 – p. 112 32 Agile Product Management with Scrum ; Roman Pichler ; Addison Wesley / Signature series 2010 ; ISBN 9780321605788 – p. 8 33 Agile Project Management with Scrum ; Ken Schwaber ; Microsoft Press 2003 ; ISBN 9780735619937 – p. 56 34 Agile Retrospectives, making good teams gréât ; Esther Derby & Diana Larsen ; Pragmatic Bookshelf 2006 ; ISBN 9780977616640 35 Project Retrospectives ; Norman L. Kerth ; Dorset House 2001 ; ISBN 9780932633446 – p. 40 36 Continuous Delivery ; Jez Humble & David Farley ; Addison Wesley / Signature series 2011 ; ISBN 9780321601919 – p. 26 37 http://en.wikipedia.org/wiki/Devops


12 / 18

Emergence et société humaine

Figure 10 : Un dirigeant de secte non identifié

Comment établit-on une religion majeure ? Suffit-il de se lever un jour et de déclarer « Je vais faire un grand truc, avec des millions de croyants organisés en paroisses, en diocèses, avec des cardinaux et moi à la tête de tout ça »38 ? Probablement pas, sauf peut-être pour le dernier point39. La route est longue depuis la naissance d’un mouvement et le moment où il atteint une ampleur planétaire. Cela ne se prévoit pas à l’avance car loin d’être une progression linéaire, les étapes intermédiaires ressemblent parfois à ça :

38 http://mb-soft.com/believe/tfc/rcatholi.htm 39 L’église émergente, apparemment, ça existe ! http://tinyurl.com/clwbecx


13 / 18

Figure 11 : Divertissement populaire à base de participants non consentants

En réalité, il faut commencer par se focaliser sur ce que l’on peut faire avec les douze (ou treize) gars que l’on a sous la main !

Dans les faits, c’est donc plutôt un modèle évolutif qu’un plan qui prédomine ici :

• D’abord un mode de fonctionnement par enseignement direct. Le maître enseigne directement à ses disciples. Le cercle est très restreint, mais les disciples très motivés et fortement impliqués dans le mouvement. Ce modèle est bien adapté à une localisation géographique restreinte, avec une forte consolidation du noyau initial.

• Ensuite un « modèle de diffusion », constitué de nombreuses petites cellules communiquant les unes avec les autres, plus ou moins sous forme de chaîne ou avec des émissaires formant le lien. Ces cellules font preuve d’un engagement fort mais moindre que celui du noyau initial40 41. Par contre ce modèle s’avère très bien adapté à une dynamique d’expansion géographique.

• Enfin une structure hiérarchisée et régulée. Ce modèle permet une gestion contrôlée et d’une organisation de très grande taille dans une finalité de garantie de la stabilité.

Chaque évolution du modèle correspond à une réponse par rapport à une nécessité du système (solidification du noyau, expansion géographique, contrôle et stabilité

40 http://www.steinbach68.org/comchret.htm 41 http://www.gric.asso.fr/gric-de-tunis/articles-21/entre-chretiens-et-musulmans/article/paul-les-premieres-communautes


14 / 18

d’une organisation de grande taille. Elle est aussi la réponse aux contraintes que l’écosystème opère sur le système (les persécutions par exemple).

En parlant d’écosystème : nous avons vu des exemples d’ampleur croissante au sein des sociétés humaines, depuis de simples projets jusqu’aux mouvements d’ampleur planétaire . Pouvons-nous étendre notre horizon à des exemples de plus grande ampleur ?

La théorie de l’évolution ou l’émergence de la vie sur terre « Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s’adaptent le mieux aux changements » Charles Darwin42

Cette célèbre citation de Charles Darwin met l’accent sur l’aspect évolutionniste et l’adaptation aux changements. L’être humain lors de sa gestation reproduit d’ailleurs en accéléré ce chemin évolutionniste. Nous pourrions mettre en vis-à-vis de la théorie évolutionniste une théorie « top down » dite préformationniste : celle des homoncules43. Cette théorie en vogue au XVIIème et au XVIIIème siècle prétendait que le sperme de l’homme contenait en fait de petits hommes préformés (mais évidemment microscopiques) qui grandissaient dans le corps de la femme. Cette théorie qui contient au moins une faille évidente (et un côté machiste assez affirmé) est pratiquement tombée dans l’oubli.

Nous en avons maintenant la conviction : le caractère dominant de l’évolution est l’émergence. Ceci est plus saillant encore dans cette seconde citation : « L’évolution procède comme un bricoleur qui pendant des millions et des millions d’années, remanierait lentement son œuvre, la retouchant sans cesse, coupant ici, allongeant là, saisissant toutes les occasions d’ajuster, de transformer, de créer » François Jacob44

Cette seconde citation met plus encore en avant le côté émergent des formes de vie, décrivant celui-ci comme… du refactoring !

Oui, le refactoring n’est pas une invention de l’extreme programming mais celui qui a permis aux formes de vie d’évoluer depuis les premières proto-bacteries, il y a 3,5 milliard d’années45…

42 The Origin of Species by means of natural sélection, or the préservation of favoured races in the struggle for life ; Charles Darwin ; John Murray, Albemarle Street 1872 43 http://en.wikipedia.org/wiki/Homunculus 44 Le Jeu des Possibles ; François Jacob ; LGF 1986 ; ISBN 9782253039075 45 http://www.ucmp.berkeley.edu/bacteria/bacteriafr.html


15 / 18

Figure 12 : Archéobactérie fossile

… Jusqu’à Justin Bieber46 !

Figure 13 : Justin Bieber, apparemment...

L’observation du caractère évolutif des espèces ne montre pas un caractère purement linéaire des formes les plus simples jusqu’aux plus complexes (j’utilise à dessein le mot « complexe » et non « évolué » dont le caractère subjectif n’est pas compatible avec la théorie de l’évolution). Certains traits évolutifs sont même apparus plusieurs fois (et ont donc disparu également) au cours des temps géologiques sous une même forme, comme l’aptitude au vol.

Dans des conditions environnementales stables, comme par exemple les zones abyssales, les espèces ont rapidement trouvé stabilité comme le démontre le cœlacanthe47 dont l’anatomie n’a pratiquement pas changée depuis le Dévonien.

46 Je ne vais quand même pas mettre une référence bibliographique pour Justin Bieber ! Soyons sérieux !! 47 https://fr.wikipedia.org/wiki/C%C5%93lacanthe


16 / 18

A contrario, lorsque les conditions environnementales changent et que la compétition pour les niches écologiques est âpre, l’explication Darwiniste prend tout son sens. Le cas le plus spectaculaire est l’extinction des Dinosaures à la fin du Crétacé48 qui a permis l’émergence des mammifères. Plus récemment, les cycles de glaciations quaternaires ont eu le même effet, mais à moins grande échelle.

Cet exemple nous donne un cadre plutôt large dans lequel on peut considérer le mécanisme de l’émergence. Voyons si nous ne pouvons pas faire encore un peu mieux !

L’univers

Figure 14 : Une galaxie qui en jette !

L’univers ! Dans sa partie visible, il comporterait 350 milliards de galaxies (auxquelles il faudrait ajouter 7000 milliards de galaxies naines) pour un total de 1022 étoiles49 50 !

48 http://www.britannica.com/EBchecked/topic/1314796/K-T-extinction 49 http://atunivers.free.fr/universe.html 50 http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/documents/ON_the_EXPANSION_of_the_UNIVERSE.pdf


17 / 18

Pourtant, dans les premières millisecondes suivant le mur de Planck51, il ne s’agissait alors que d’une soupe de gluons-quarks52 puis des atomes d’hydrogène et d’hélium. Il faudra attendre la naissance des premières étoiles pour que des éléments plus lourds soient formés pour donner naissance à des éléments plus complexes. Ces éléments sont libérés dans l’espace interstellaire lorsque meurent les étoiles lors des spectaculaires super nova pour former les corps telluriques accompagnant les genèses stellaires suivantes. Je veux bien entendu parler de notre terre et de ce qui s’y est développé, car comme nous l’a fait remarqué Hubert Reeves : nous sommes tous des poussières d’étoiles53 !

La formation de l’univers, son entropie54 et son expansion actuelle sont des phénomènes purement émergents, guidés par les seules lois de la physique.

Conclusion Doit-on conclure que l’approche « top-down » est vouée à l’échec ? Certainement pas. Certaines des grandes réalisations de l’humanité ont abouti en suivant un plan. De nombreux projets informatiques ont été menés et réussi de même. D’autres à venir le seront aussi. Mener des projets ainsi est aussi plus rassurant car il permet de se conformer à ce plan sans se remettre en cause.

Mais on ne peut pas nier l’évidence sur l’approche émergente : son existence et ses réussites spectaculaires. Elle est l’essence du progrès et comme nous le rappelle Newton : « Si j’ai vu si loin, c’est que j’étais monté sur des épaules de géants »

Isaac Newton55

Elle surpasse en ampleur ce que l’on peut faire avec une approche descendante et précède dans le temps cette dernière de plus de 13 milliard d’années.

L’auteur Christophe Addinquy est un adepte de la première heure des "Design Patterns". Il a appliqué depuis plus de 15 ans les techniques de remaniement du code et d'émergence du Design. Il a par la suite eu l'occasion de mettre en œuvre ces idées au niveau de l'architecture d'une librairie de pricing des produits financiers puis de systèmes d'information (dans le cadre de missions d'Urbanisme ou en tant que responsable IT).

51 http://www.techno-science.net/?onglet=glossaire&definition=2845 52 http://fr.wikipedia.org/wiki/Plasma_quark-gluon 53 Poussières d’étoiles, Hubert Reeves ; éditions du Seuil 1984 – ISBN : 2-02-022407-0 54 Une brève histoire du temps, Stephen Hawkins ; Flammarion 1989 ; ISBN : 2-08-08123-6 ; chap. 9 « La flèche du temps » 55 Lettre à Robert Hooke, 5 février 1675


18 / 18

Pour le contacter ou le suivre

mail [email protected]

twitter @addinquy

LinkedIn addinquy

Blog http://addinquy.tumblr.com/

Google+ addinquy

Quora addinquy

Remerciements et crédits Cet article fait suite à la présentation faite sous forme de « Lightning Talk56 » lors du Scrum Day 201257 58 le 27 mars à Paris.

Crédits

L’illustration 14 : iStockPhoto.com, nmr : 17031940

Remerciements

Merci à Véronique Messager pour sa relecture minutieuse et pertinente.

56 http://addinquy.tumblr.com/post/17547131381/qui-a-peur-du-lightning-talk 57 Le Scrum Day est un événement annuel organisé par le French Scrum User Group (FSUG) http://www.meetup.com/frenchsug/ et http://www.frenchsug.org/display/FRSUG/French+Scrum+User+Group 58 Le site officiel du Scrum Day http://www.scrumday.fr/

Les vertus de l'émergence

Documents

Transcript of Les vertus de l'émergence