L’évolution d’Integromat en Make a mis en ébullition toute la sphère du no-code, et à notre avis, c’est justifié. Mais peut-être pas pour les raisons qu'on croit.
Évidemment, tout le monde s’est fait des gorges chaudes du rebranding (visible et coûteux), et de l’ajout des nouvelles fonctionnalités (qui n’aime pas les nouveaux jouets ?), mais je pense, pour ma part, que le vrai changement se trouve dans la partie immergée de l’iceberg.
Ce qui manque au no-code d’aujourd’hui
Depuis toujours, les personnes qui ne partagent pas les mêmes objectifs directs ont du mal à se mettre en phase. En informatique, les développeurs (dev) écrivaient leur code et les ops déployaient le logiciel ainsi écrit sur les machines et étaient responsables de la bonne tenue du service. Et évidemment, en cas de problème, tout ce joyeux monde se renvoyait la responsabilité. Pour réconcilier les deux camps, il a fallu inventer le DevOps, un peu comme on a réconcilié les chauves-souris et les hommes en créant Batman.
De la même façon, à l’heure où j’écris, le no-code divise, comme le mentionnait Karen dans son précédent article : beaucoup de développeurs et d’ops voient encore le no-code comme un jouet qu’on ne peut utiliser que dans des circonstances très particulières.
Et vous savez quoi ? Jusqu’à un certain point, ils ont raison. Nous avons beau être partisan du no-code et croire en la révolution qu’il apporte, la vérité, c’est que quand on définit Breizh e-nov comme une “agence no-code”, ce n'est que partiellement exact. Déjà parce que nous ne faisons pas que du no-code (nous faisons aussi du cloud et nous travaillons l’inter-opérabilité no-code/cloud), mais surtout, il y a une réelle motivation pour cela.
Pourquoi ? Eh bien, parce qu’il manque au no-code tel qu’on le pratique aujourd’hui, quelque chose de crucial, qu’on a touché du doigt dans notre précédent billet : l’observabilité.
Code à la joie
L’observabilité, c’est la capacité à déterminer l’état d’un système grâce à des indicateurs.
Et sur ce plan, l’écrasante majorité des outils no-code se comporte virtuellement comme une boîte noire : on ne sait pas toujours si ça a bien marché ou pas, et presque jamais pourquoi ça n’a pas (bien) marché.
Reprenons le cas d’Integromat (avant qu’il ne devienne Make) : on pouvait activement gérer des cas d’erreur, mais lorsque qu’une erreur non prise en charge survenait, on ne pouvait que constater à l’occasion, que le scénario n’avait pas fonctionné comme prévu. En quelque sorte, avant de constater le résultat, l’opacité du système faisait qu’on pouvait presque le qualifier de scénario de Schrödinger.
C’est là une différence fondamentale avec le code de l’informatique traditionnelle qui, lorsqu’il est bien décliné, est instrumenté pour pouvoir être observé, de sorte qu’on puisse savoir pourquoi une opération s’est mal déroulée.
C’est peut-être un détail pour vous
mais pour nous, ça veut vraiment dire beaucoup. Parce qu’en production, certains systèmes sont ultra-critiques. Prenons par exemple, le système d’une société de transport qui calcule pendant la nuit les tournées du lendemain. Si son opération échoue et que l’on ne s’en rend compte qu’au matin, les camions ne peuvent pas partir. On vous laisse faire le calcul du manque à gagner et du coût des intervenants désœuvrés.
Un tel système mériterait sans doute un dispositif approprié pour que sa supervision soit assurée, et que des indicateurs soient mis en place pour en permettre une réparation rapide.
Make You Feel My Love (ft. Adèle)
Il semblerait qu’Integromat, à l’occasion de sa mutation en Make, ait entendu les cris de nos âmes. En effet, dans leur API, il existe désormais un moyen facile de récupérer les journaux d’exécution d’un scénario. Plus fort encore, le module Make utilisable dans un scénario Make expose cette méthode. Le propos de Make lors de leur annonce officielle, “ability to automate your automations”, nous l’avons comprise comme “la capacité à automatiser la supervision de nos automatisations”. Et ça, quand on gère des systèmes de production, ça devient un game changer car cela signifie que désormais, on est en capacité de savoir en temps quasi-réel si un scénario a échoué (mais toujours pas pourquoi !), diminuer notre temps de réponse, et réagir en conséquence.
Je pense qu’on peut s’accorder facilement sur la différence dans la relation client entre un “Bonjour, nous avons détecté que votre automatisation n’a pas fonctionné il y a 10 minutes, mais nous sommes déjà en train de nous en occuper” de notre propre initiative, et un “Les bons de commande du jour n’ont pas été envoyés hier soir, mes clients ne vont pas être livrés, comment je fais maintenant ?” venant du client.
Alors certes, la surveillance (monitoring) n’est qu’un petit sous-ensemble de de l’observabilité, mais ne dit-on pas que “au royaume des aveugles, les borgnes sont rois” ?
En tout cas, cela semble être un pas dans le bon sens.
Et si tous les éditeurs no-code le leur emboîtent, ce pas, alors peut-être que le no-code pourra finalement être, à juste titre, considéré comme une option viable pour des systèmes critiques de production.
Pendant ce temps, à Vera Cruz
Soyons réalistes, il y a peu de chances pour que les choses changent fondamentalement en peu de temps (à moins peut-être que vous ne nous aidiez à diffuser trèèèèès largement ce billet !).
À Breizh e-nov, nous allons donc probablement continuer encore quelque temps à œuvrer selon notre croyance et encore et toujours, choisir le bon outil pour le bon usage.
Et en particulier, le no-code pour accélérer sur les parties peu critiques, et le code dans le cloud instrumenté pour traitement critiques.
En ce sens, c’est peut-être là-dessus qu'on ne fera jamais de compromis.
Et vous, avez-vous des solutions pour assurer la continuité de vos services critiques en production ? Prenez contact avec nous et discutons-en ensemble !