Le manifeste livecorp

Vous arrive-t-il de vous pincer ou pincer un collègue, pour savoir si vous êtes des robots ? Parce que lorsqu'on répète les mêmes tâches en boucle en suivant aveuglément un objectif sans pouvoir prendre de recul, on peut se poser la question !

Dans le monde du développement il y a une pratique naïve pour transmettre une information asynchrone : le polling (scrutation, en français — interroger quelqu'un ou quelque chose à intervalles réguliers pour savoir si, cette fois, la réponse est arrivée). C'est la technique la plus simple, et de très loin la plus coûteuse, puisque la machine qui fait du polling passe l'essentiel de son temps à poser une question dont la réponse est « non, pas encore ». Et dans beaucoup d'organisations, ce rôle est tenu par des humains !

Votre entreprise est un algorithme

Si cet exemple s'applique aussi bien, ce n'est pas par coquetterie de vocabulaire. Une organisation est un algorithme : des entités qui détiennent chacune une part d'information, des messages qui circulent entre elles, des files d'attente, des reprises sur erreur, pour produire un résultat en fin de chaîne. La seule différence avec le code, c'est que cet algorithme-là est exécuté par ou avec des personnes — et qu'il est rarement ingénierié de bout en bout. Mais il comporte les mêmes risques de dette technique !

La bonne nouvelle : un algorithme se relit, et surtout, il se refactorise. Des patterns existent, ils ont été étudiés, et certains sont mesurablement meilleurs que d'autres pour un problème donné.

La dette technique de votre organisation

Alors relisons. Quatre motifs reviennent, et ils portent tous un nom chez les développeurs.

Le polling, on vient de le voir : on relance, on rouvre le fil de discussion, on retourne voir si le document aurait bougé depuis tout à l'heure.

Le goulot d'étranglement : la personne par qui tout passe. Son absence n'est pas un contretemps, c'est un arrêt.

L'état partagé : la même information ressaisie dans deux logiciels qui s'ignorent. Deux vérités, et personne pour dire laquelle est la bonne.

L'attente bloquante : une équipe qui patiente devant un feu passé au vert depuis vingt minutes.

Aucun des quatre ne provoque de crise. Ils ralentissent, discrètement, en permanence. La facture existe quand même : elle se règle en réunions de recalage, en délais qu'on n'explique pas au client, et en cette fatigue diffuse que personne ne rattache jamais à sa cause.

Le réflexe habituel, quand on veut regagner du temps, consiste à ajouter un dispositif : un point quotidien de synchronisation, un tableau de suivi mis à jour le vendredi, un canal dédié aux relances. On empile des rituels dont l'unique fonction est de compenser le fait que rien n'est transmis automatiquement. C'est déplacer le travail au lieu de le supprimer.

La bonne question n'est donc pas « comment mieux s'organiser pour aller chercher », mais qu'est-ce que le système devrait envoyer de lui-même, et à qui ?

C'est au système d'envoyer

Une facture validée, un test qui casse, un client qui répond, un dossier qui change d'étape : ce sont des événements. Ils sont datés, ils ont un émetteur. Rien n'oblige à ce qu'ils dorment dans une base de données en attendant qu'un humain vienne les réveiller.

Le renversement porte un nom en développement : on passe du pull (j'interroge) au push (on me prévient). Le canal, aujourd'hui, c'est la socket — une connexion qui reste ouverte entre le poste de travail et le serveur, et dans laquelle l'événement part au moment même où il se produit. Chaque brique publie ce qui lui arrive, les autres s'abonnent à ce qui les concerne. C'est ce qui fait qu'une application bancaire signale un paiement trois secondes après que la carte a été posée.

Push first, c'est adopter ce réflexe dès la conception d'un outil métier : pour chaque événement, savoir qui doit l'apprendre, à quel moment et sur quel canal. Pas dans une hypothétique v2.

Et non, il ne s'agit pas de surveillance : le système annonce les événements à ceux qu'ils concernent, et à eux seuls.

Le push a son revers : une notification mal dosée interrompt, et l'interruption se paie. Gloria Mark, chercheuse à l'université de Californie à Irvine, l'a mesurée — 23 minutes et 15 secondes pour revenir pour de bon à une tâche quittée. Une pastille rouge posée sur chaque événement de l'application ne fait donc pas gagner la journée, elle la découpe en confettis. Ce qu'il faut envoyer, à qui, sous quelle forme et à quel rythme est un métier à part entière, et nous y reviendrons.

Ce pattern a un nom

Le push règle le polling. Il ne dit rien des trois autres motifs — le goulot, l'état partagé, l'attente. Or ils se corrigent ensemble, parce qu'ils sont les symptômes d'un même pattern manquant, formalisé par Carl Hewitt en 1973 et devenu depuis un classique de la programmation concurrente : le modèle acteur.

Un acteur est une entité qui détient son propre état, reçoit ses messages dans une boîte aux lettres, les traite un par un à son rythme, et peut à son tour envoyer des messages ou créer d'autres acteurs. Trois règles, pas une de plus : aucune mémoire partagée, une communication uniquement par messages, et personne qui attende personne. Reprenez les quatre motifs de tout à l'heure : ces trois règles les interdisent un par un.

Transposé à une équipe : personne ne va lire dans la mémoire du voisin, et c'est la fin du « tu peux me faire un point ? ». Celui qui envoie dépose et retourne travailler ; celui qui reçoit traite quand il est disponible, un sujet à la fois. Et lorsqu'un acteur tombe, le système ne s'effondre pas : dans la bibliothèque OTP d'Erlang, un superviseur ne fait pas le travail, il sait seulement quoi relancer et dans quel ordre. Votre goulot d'étranglement devient une absence qui ne bloque plus la chaîne.

Si ce vocabulaire de boîtes aux lettres sonne mécanique, c'est que le modèle cache mal son inspiration : le vivant. Alan Kay, à qui l'on doit la programmation objet, disait avoir pensé ses objets comme des cellules — chacune dans sa membrane, aucune n'allant lire l'intérieur d'une autre. Votre corps ne fait jamais de polling : vous ne vérifiez pas toutes les trois secondes que votre main n'est pas posée sur la plaque du four. Le système nerveux pousse le signal à l'instant du contact, et la moelle épinière déclenche le retrait avant même que le cerveau en soit informé. Décision locale, message urgent, aucun goulot central — et un organisme remplace ses cellules sans jamais s'arrêter de vivre.

C'est de là que vient notre nom. Une livecorp est une organisation qui réduit la distance entre ce qui se passe et ce que les équipes en perçoivent : live comme « en direct », et live comme « vivant ». « Organique » n'est donc pas une métaphore d'ambiance dans ce manifeste, c'est un cahier des charges.

Pour cette classe de problèmes — beaucoup d'entités autonomes, des communications qui peuvent échouer, aucune synchronisation générale possible — le modèle acteur est le seul dont le coût de coordination n'explose pas quand on ajoute du monde. C'est cela, « mesurablement meilleur ». Et ce n'est pas une intuition de blog : Ericsson a créé Erlang pour des commutateurs téléphoniques qui ne peuvent pas s'arrêter, WhatsApp a tenu des millions de connexions simultanées par serveur avec une équipe technique qui tenait dans une salle de réunion.

C'est le pattern que nous utilisons — il ne dispense pas de concevoir les messages eux-mêmes : un message qui n'apprend rien à celui qui le reçoit coûte une interruption pour rien. L'ordre d'arrivée, les pertes et les doublons restent à traiter explicitement.

Ce que le système retient, vous pouvez l'oublier

La charge mentale, ce sont ces choses qu'on garde ouvertes dans un coin de la tête faute de pouvoir les confier à quelqu'un ou à quelque chose : relancer le devis, vérifier que le virement est parti, se souvenir que ce client-là préfère être appelé avant onze heures.

Elle ne vient pas du métier. Elle vient de tout ce qu'on demande de compenser à la main : ressaisir la même information dans deux logiciels qui s'ignorent, revérifier par précaution, rester seul à tout suivre pour que rien ne se perde.

Un système qui prévient au bon moment ne fait pas que faire gagner des minutes : il autorise à oublier — et c'est la différence qui se ressent le dimanche soir. Tant qu'une information dort dans un coin du système sans que rien ne l'envoie à qui de droit, c'est la mémoire des équipes qui sert de sauvegarde. Elle travaille même quand l'ordinateur est fermé.

Le bien-être au travail n'est donc pas un supplément qu'on ajoute une fois la performance sécurisée : il mesure la santé du système. Quand une organisation demande à ses équipes de relancer, de mémoriser et de recoller les morceaux, ce sont les personnes qui absorbent ce que la machine ne fait pas.

L'analogie touche ici sa limite : un acteur au sens de Hewitt ne se lasse pas, ne cherche pas de sens à ce qu'il fait et ne tient à personne dans son équipe. Une organisation n'est donc pas seulement un algorithme — mais elle en est un aussi, et c'est cette part-là qu'on peut relire, mesurer et corriger sans rien demander de plus à personne.

Personne n'attend personne

Travailler ensemble s'est longtemps traduit par « être disponibles en même temps », ce qui suppose que tout le monde soit là — et personne n'est jamais tout à fait là. Quand le système diffuse lui-même les événements, la synchronisation cesse d'être une condition d'entrée : l'état d'un dossier se retrouve en arrivant, sans qu'un collègue ait à le raconter. Le gain auquel nous tenons le plus est là — le droit de ne pas être interrompu pendant deux heures sans que le travail des autres s'arrête pour autant.

Car la file indienne est rarement imposée par la nature des tâches ; elle l'est par la vitesse de l'information. Dès que celle-ci arrive à temps, une équipe prépare la suite pendant qu'une autre termine, et un problème se traite à son apparition plutôt qu'au moment où il remonte. Pour qui dirige, plus besoin de reconstituer la situation à partir de sources éparses et parfois contradictoires : l'état de l'entreprise devient lisible par lui-même.

« Je ne suis pas un robot »

Le but n'a jamais été de moins ressembler à un robot. C'est d'arrêter de tenir, dans l'algorithme, le seul rôle qu'une machine remplit mieux que nous : attendre, relancer, se souvenir, recopier d'un outil à l'autre. Tout le reste est parfaitement irremplaçable et le restera — décider avec des informations incomplètes, arbitrer entre deux urgences qui ont chacune raison, dire non à un client, deviner qu'il faut appeler celui-là avant onze heures.

Que le système envoie, que les équipes décident : tout le partage des rôles est là, et le pattern qui le rend possible est connu, éprouvé, disponible depuis un demi-siècle. Le reste — sockets ouvertes, files de messages, superviseurs, notifications qui portent une action — n'est que de la plomberie. Une plomberie que nous savons faire.

Et elle s'installe pièce par pièce. Un système d'acteurs ne se déploie jamais d'un bloc, et une organisation pas davantage. Faire parvenir une information critique directement à la bonne personne, supprimer une double saisie, permettre à deux équipes d'avancer sans attendre un relais. Ni grande migration, ni chantier de dix-huit mois : une seule question pour commencer — où le temps se perd-il aujourd'hui ? — puis un sujet à la fois, à partir de ce qui est déjà là.

Quant au test du pincement, vous pouvez le ranger : il ne reste qu'un endroit où l'on vous demande encore de prouver que vous n'êtes pas un robot — une petite case à cocher, au détour d'un formulaire. Le jour où l'attente, les relances et la mémoire seront rendues aux machines, vous pourrez enfin la cocher en toute bonne foi…