Oh, le beau framework maison !

Nombreuses sont les entreprises qui développent simultanément plusieurs logiciels. Souvent, la recherche d'efficience les conduit à créer un framework maison.

Une excellente idée, à fuir d'urgence.

Prenons le cas d'une ESN développant des applications de gestion pour le compte de ses clients. Les projets allant, elle constate qu'une application de gestion, c'est au fond un peu toujours la même chose : des objets métier qu'on liste et qu'on consulte en détail pour les modifier. On peut y voir un pattern "master/detail", ou, plus prosaïquement, la répétition d'une sempiternelle "to do list". Rien de bien sorcier, donc.

Forte de cette idée, notre ESN établit sa stack maison : React, Fastify et PostgreSQL. C'est vrai, après tout : cela facilite le passage d'un développeur d'un projet à un autre.

Pourtant, c'est le début des ennuis et la dernière chose à faire.

L'architecture et le choix des technologies sont guidés par les contraintes du métier : ici on aura une exigence particulière sur les temps de réponse, là sur la confidentialité des données, là sur leur intégrité. Cela nous guide parfois vers des solutions complexes, oui, mais parce que cela est nécessaire.

À l'inverse, partir de la technologie, c'est mettre la solution avant le problème, c'est faire des choses inutilement compliquées et, finalement, s'inventer de nouveaux problèmes. C'est du solutionnisme technologique et c'est la malédiction des informaticiens. I ❤️ Kubernetes : ouais…

Au-delà, cette standardisation technologique est un appauvrissement. Moi, développeur, je me retrouve à faire peu ou prou toujours la même chose. C'est juste le métier qui change, mais bon, hein, le métier… Mon job devient de l'abattage et mon esprit s'éteint doucement en fixant les aiguilles de la pendule 🕜

Mais on peut faire pire (toujours, soyez confiants) : on peut faire un framework maison. Oui, un bon cadre bien rigide, qui peine à intégrer nos demandes d'évolution et met tous les projets en retard, parce qu'il n'y a que 2 devs qui bossent dessus jour et nuit et s'épuisent à essayer de colmater les brèches. S'il faut utiliser un framework, autant que ce soit un framework du marché, maintenu par une large communauté.

Mais au fait : c'est quoi, un framework ?

Un framework se définit par l'inversion de contrôle : c'est le framework qui appelle mon code, par opposition à une librairie, à laquelle mon code doit faire appel explicitement. Je n'ai donc plus qu'à écrire un peu de code là où il faut, je sais pas bien comment ça marche mais ça marche. C'est bien le but, d'ailleurs, et c'est tout le danger.

Parce qu'implicitement, l'entreprise fait la différence entre ceux qui doivent "pisser du code" au kilomètre et ceux qui réfléchissent. Le problème fondamental est donc bien une forme de taylorisme, qui, déjà préjudiciable sur une ligne de production, n'a de surcroît aucun sens dans le monde du logiciel. L'industrialisation a ses limites.

Que faire alors ?

Deux choses relativement simples :

• De manière transverse, développer des composants (authentification, gestion des droits applicatifs, design system…) et les mettre à disposition des équipes au travers de standards tels que les Web Components ;

• Laisser à chaque équipe projet/produit le choix de l'architecture et des technologies en utilisant ces briques quand nécessaire. Autrement dit, leur faire confiance, et obtenir le meilleur en retour.

Le produit fini n'en sera que meilleur, de même que la santé mentale de vos développeurs 🙏