Transformer, ce n’est pas seulement passer son temps à chercher du budget et à arbitrer des plannings. Non, transformer, c’est surtout concevoir, rendre possible, et concrétiser. Ce matin-là, je viens avec les croissants et une mauvaise nouvelle. L’architecte le sent tout de suite.
― Les sponsors ont tranché. On ne pourra pas attendre d’avoir le nouveau backend pour lancer le front. Ça n’arrange pas nos affaires, mais nous devons trouver une solution.
Il me regarde, étonné. Comment ai-je pu céder sur un point aussi critique ? Il finit par lâcher :
― Ça ne marchera pas. Si on n’a pas de backend, on fait une vitrine sans la boutique.
J’avais sorti le même argument la veille au soir, sans succès. Je hausse les épaules.
― Je ne vois plus qu’une solution : construire notre propre bus d’évènements en attendant qu’ils trouvent un remplaçant pour reprendre le sujet, et un connecteur pour parler avec le système legacy.
On parlait de recréer toutes les fonctionnalités attendues d’un middleware leader du marché. Un travail titanesque même pour une entreprise tech, ce que nous n’étions pas.
Mon architecte se creuse la tête. Il voit bien lui aussi que nous nous embarquons dans une voie impossible.
― Si on fait du point à point, on peut s’en sortir. Ça ne tiendra pas indéfiniment, mais, pour un MVP, ça pourrait suffire. Après, ça fera trop de données à gérer.
Je consulte le planning. Sa solution nous ferait gagner six mois. Bien. Très bien même. Mais pas assez. Et renforcer l’équipe pourrait bien en prendre trois.
Une gorgée de café. Il nous faut autre chose.
Une blague, un commentaire sur les enfants qui grandissent, n’importe quoi pour sortir du schéma mental de l’impasse.
Je reprends les notes. Toujours rien.
Et puis… Oui, peut-être…
Je griffonne un schéma sur mon carnet.
― Et si… Et si au lieu de transporter toute la donnée, chaque service se contentait de dire « j’ai du nouveau » ?
Le regard de mon architecte change. Il prend mon carnet et commence à dessiner.
― Ça pourrait marcher. Il faudrait n’envoyer que des notifications d’état sur un service orchestrateur. Chaque service pourrait alors l’interroger pour connaître l’état de tous les autres. La donnée reste exposée mais pas besoin de la faire transiter à chaque opération. »
Après trois heures à explorer l’idée sous tous les angles – faisabilité, scalabilité, performance, robustesse, etc. – nous venons d’ébaucher un nouveau pattern propriétaire : le lightweight metadata and event-driven orchestrated choregraphy, (LMEDOC). Le travail peut reprendre.
Il reste à trouver un nom plus sexy pour ce concept si je veux que les sponsors se l’approprient. Parfois la valeur tient juste au fait de bien nommer les choses.