Il y a 18 ans, nous venions de gagner un projet qui concrétisait notre passage au web et à .Net. Un jeune développeur est alors venu vers Hervé : « Avec ce passage à l’objet, est ce qu’on ne pourrait pas faire des composants, travailler en réutilisable ? ».
Bien sûr, il y aurait un surcoût au projet (et ça a été bien plus que prévu) mais l’idée nous a plu et nous avons démarré notre histoire de toolkits .Net.
Au départ, ce fut la grille : en effet, les petites applications commencent souvent avec un tableau Excel, quelques macros, puis, pour que les utilisateurs clients acceptent la webisation de leurs outils métier, il fallait offrir des facilités de manipulation : filtres, tris, exports… Les connecteurs multi SGBD, KPI, et bien d’autres objets ont suivi.
Aujourd’hui, le jeune développeur est devenu notre responsable R&D et notre dernier toolkit LAGOON, est en phase de consolidation, avec une vingtaine de projets réalisés.
18 ans après, témoignons de ce chemin technique :
Les risques
- Chaque version est un pari, sur les choix techniques et la capacité à rentabiliser l’investissement
- Ce choix limite la possibilité de sous-traiter : programmer avec notre toolkit nécessite une formation. Il faut un peu de continuité pour l’amortir.
Les avantages
- Gains de productivité et de maintenabilité
- Fiabilité : environ 30% du code de nos applications est composant, donc très stable.
- Expérience utilisateur : chaque application bénéficie de bonus ergonomiques (intégrés aux composants),
- Des fonctionnalités toutes prêtes : gestion d’erreurs, gestion des langues …
Surtout, cette politique rend concret la notion d’équipe, de remplaçabilité. Elle nous permet de tenir nos engagements de réactivité & qualité.
Les objections
- Est-ce que les clients acceptent cette focalisation technique ? En fait, nos clients apprécient cette capitalisation technique : les gains en maintenabilité, en ergonomie et aussi la possibilité de customiser le toolkit à leur design system comme à leur plate-forme technique (SGBD, authentification, infra …) ; nous construisons ensemble un parc homogène d’applications métiers.
- Est-ce que ça ne bride pas la créativité du développeur ? Au contraire, le développeur ne perd pas de temps sur des fonctions « banales » et peut se concentrer à des ergonomies ou des algorithmes facilitant le travail des utilisateurs.
Et puis, il y a eu des sujets à traiter
- Toolkit propriétaire ou open source ?
- Montée en compétences des collaborateurs
- Passage d’infos sur les MAJ (release notes), les nouvelles pratiques.
Nous en parlerons alors dans un prochain article.
