No-code : l'Excel des temps modernes

• Organisation

Excel, un outil merveilleux

N’y voyez rien de péjoratif ni de moqueur, au contraire.

Excel nous accompagne depuis 1987 pour le meilleur et pour le pire :

• Le meilleur : Excel permet de prototyper une idée en quelques heures. Commencer à structurer l’information et la répartir en plusieurs onglets ou fichiers (différents bounded contexts ?). Cela permet de démarrer rapidement quand on n’est pas sûr de savoir ce dont on a besoin, d’apprendre, de répondre à nos propres questionnements etc. En gros, faire un POC, voir si ça nous aide et, à la longue, si ça suffit ou s’il faut créer une vraie application.

• Le pire : la loi de l’instrument. Si le seul outil dont vous disposez est un marteau, vous aurez tendance à ne voir que des clous… quand bien même vous avez affaire à une vis. Faire tout avec Excel parce qu’on ne connaît que ça et qu’on maîtrise l’outil sur le bout des doigts. Donc en faire trop, inexorablement : une bonne grosse dose de VBA, rapidement inmaintenable et source de nombreuses failles de sécurité. Cela devient du développement, mais du développement fait par des gens dont ça n’est pas le métier. Et à la fin, c’est le département informatique qui récupère le sac de nœuds après que le crash a eu lieu (Shadow IT).

Quelle place donner au low-code/no-code ?

Les outils de low-code/no-code (Retool, Bubble, SAP Build et Airtable pour ne citer que les plus connus) présentent à mes yeux le même intérêt que ce bon vieil Excel :

• Ils favorisent l’autonomie des équipes métier, donc l’innovation ;

• Ils déchargent l’IT des sujets à moindre valeur ajoutée : workflows de validation, tâches d’administration technique, back-offices ou même front-offices simples (disons CRUD) ;

• Au final, ils permettent de répondre rapidement à des demandes simples, donc de gagner en Agilité à l’échelle de l’entreprise.

En tant que développeur ou CTO, il est facile de ricaner et considérer cela du haut de sa superbe. Pourtant, nous serions bien inspirés de regarder ces outils de près.

Le tout reste de savoir encadrer la pratique : que le métier prenne les devants est une bonne chose, mais il convient d’accompagner le mouvement.

Accompagner le mouvement

Il y a 15 ans, j’ai travaillé en stage chez un grand énergéticien français, qui est à présent en passe d’être nationalisé (on voit pas du tout de qui il s’agit). Une équipe de 3 ou 4 développeurs travaillait à proximité des traders pour faire ça proprement et éviter que ça parte dans tous les sens. On appelait ça les Développements Rapides (DR) et ça marchait très bien.

Voici justement quelques suggestions :

• Préconiser un outil, afin de mutualiser le savoir-faire et les coûts à l’échelle de l’entreprise (parce que bon, c’est pas donné non plus) ;

• Faire connaître les bonnes pratiques de manière à limiter la dette technique (anticiper le jour où vous en ferez une vraie application) ;

• Se réinterroger sans cesse sur la dépendance à la plateforme, puisque ces dernières sont libres de changer les termes du contrat du jour au lendemain, voire de cesser leur activité.

Quoi qu’il en soit, le recours au low-code/no-code prend totalement son sens dans le cadre d’une approche Domain-Driven Design (DDD). La question du « make or buy », qui se pose pour chaque contexte, bénéficie à présent d’un nouvel entre-deux.