Vers une Ingénierie Holistique des systèmes de développement

Par Philippe Anel, CEO de DREMML

Depuis plus de 30 ans, je développe des applications - du code bas niveau pour du hardware jusqu'à des applications web modernes, en passant par des bibliothèques de calcul pour l'aérospatiale [1]. À force d'expérimenter, de prototyper, de pivoter et de jeter une quantité astronomique de code à la poubelle, j'ai affiné une façon de travailler qui ne me semble pas rentrer vraiment dans les cases classiques.

J'appelle ça « Ingénierie Holistique des Systèmes d'Information » : un nom ambitieux qui me fait rire, mais il représente assez bien une réflexion issue de ma pratique : concevoir des systèmes en tenant compte de toutes les parties : technique, matériel, besoins métiers, données, utilisateurs – sans isoler les éléments. Ici le mot Holistique signifie « penser les interactions entre code, matériel, utilisateurs et données comme un écosystème unique ».

C'est comme du System Thinking appliqué au développement : on pense les interactions, on construit en itérant, et on ajuste en temps réel. Ce que ça change concrètement :

• Prototypage ultra-rapide : Livrer un MVP en quelques semaines, même pour des projets complexes, tout en gardant une architecture modulaire.
• Adaptabilité sans compromis : Des systèmes pensés pour pivoter facilement, sans sacrifier la scalabilité ou la robustesse.
• Décisions éclairées, basées sur les données : Intégrer des métriques et des logs dès le départ pour guider les évolutions et optimiser en continu.
• Une vision globale : Aligner technique et métier pour éviter les silos et les réécritures coûteuses.

Cette approche m'a permis de livrer des solutions qui répondent vraiment aux besoins, tout en restant agile face à l'incertitude. De fait, le client a souvent une idée précise de ce qu'il attend et c'est une bonne chose, puisque c'est lui qui fait face au métier.

Mais le développement d'application nécessite également la mise en place de métriques pour pouvoir répondre rapidement à la réalité du terrain. Dans tous mes projets, je n'hésite pas à ajouter un maximum de logs avec pas mal de timings, en les rendant filtrables lorsque j'effectue des recherches. Grâce à ça, je peux très rapidement identifier un bug et identifier les parties du code qu'il me faut optimiser.

Les frictions entre client (MOA : maître d'ouvrage) et développeur (MOE : maître d'œuvre) surviennent souvent quand l'investissement initial ne correspond pas à la réalité. Les petites structures négligent fréquemment le pilotage, laissant les équipes techniques gérer seules délais, budget et qualité.

Un cas concret : pivoter 7 fois en quelques semaines

Dans un de mes projets par exemple, j'ai été conduit à développer une application conçue pour envoyer des SMS à des leads suivant une logique bien particulière (en respect de la RGPD bien entendu). Conscient que cette « logique » métier pouvait être changée rapidement pour s'adapter aux métriques mises en place, j'ai décidé dès le départ de partir du principe que j'aurai plusieurs algorithmes à mettre en place.

C'est une décision qui m'a coûté un peu plus de travail initial que ce qui était prévu. Mais bien m'en a pris, puisqu'à la fin, nous avons eu à changer 7 fois cette partie en quelques semaines. Les pivots sont fréquents dans un MVP, surtout pour saisir une opportunité rapidement.

Alors cette méthode demande un investissement initial important :

• accepter de remettre en question ses choix,
• identifier très vite les risques potentiels,
• collaborer étroitement avec les équipes métiers (ce sont eux qui connaissent la réalité du terrain)
• et ne pas avoir peur de repartir de zéro si besoin.

Cette méthode demande beaucoup d'énergie, ne convient pas à tous les développeurs et exige une forte implication du métier et des décideurs.

Au départ, les objections sont souvent nombreuses tant cette méthode bouscule les habitudes. Mais une fois impliquées, les équipes concernées ressentent souvent une fierté d'avoir contribué à optimiser l'outil sur lequel elles travaillent. En tant que MOE, j'accompagne les équipes pour dépasser ces objections, en montrant comment leur implication directe améliore l'outil.

Un autre exemple : gestion de crise

Mais en cas de coup dûr, je suis convaincu que ça en vaut la peine. Parce que cette maîtrise de tous les éléments permet un pivot fonctionnel rapide, par exemple lors d'un imprévu technique, par exemple la panne d'une API tierce (dans mon cas, une API de signature électronique) qui bloque tout le métier. Grâce à notre architecture modulaire, nous étions prêts à basculer vers une autre API en quelques heures, mais le service s'est rétabli rapidement. Mais c'est surtout le fait d'avoir loggé toutes les procédures bloquées dans la journée qui nous a permis, avec quelques scripts, de relancer tous les process en souffrance.

Conclusion

Je ne prétends pas avoir inventé la roue. Cette façon de faire emprunte à l'Agile, Scrum, Kanban, au DevOps, au Lean, et à l'ingénierie système et à tout ce que j'ai pu picorer ici ou là, principalement parce que chacune de ces méthodes prises à part me donner l'impression de m'enfermer, mais j'essaye de les combiner d'une manière qui me semble différente.

Je suis convaincu de ne pas être le seul à travailler ainsi. Par curiosité et afin de l'expliquer à mes clients autrement qu'avec mes mots, j'ai cherché des méthodes similaires, mais aucune ne regroupe toutes ces pratiques. Les plus proches sont sans doute le Domain-Driven Design (DDD) et le Site Reliability Engineering (SRE).

Mais là où DDD se focalise sur la modélisation du domaine et SRE sur la fiabilité en production, cette approche intègre ces aspects dès la conception, par pragmatisme d'abord, tout en anticipant les pivots grâce à une architecture modulaire et des métriques. Par ailleurs, mon approche mobilise les équipes métier dès la conception, transformant les objections en fierté collective, contrairement à DDD ou SRE.

Je me trompe peut-être, mais dans le projet SMS sus-mentioné, DDD aurait requis une refonte lourde du modèle de domaine à chaque pivot, et SRE aurait été moins pertinent en phase de conception. Mon approche, avec une architecture modulaire et des métriques dès le départ, a permis 7 pivots en quelques semaines sans douleur.

Pour résumer, mon approche se distingue par son caractère global, sa flexibilité et son intégration pragmatique de multiples disciplines. Cette approche réduit les coûts à long terme en évitant les réécritures et accélère la mise sur le marché, même face à des imprévus.

En anticipant les pivots, cette approche évite des réécritures coûteuses, souvent responsables de nombreux dépassements budgétaires dans les projets informatiques.

Peut-être en connaissez-vous une autre méthode ?

Avez-vous déjà géré des pivots multiples dans un MVP ? Quels outils ou pratiques vous ont permis de rester agile face à une panne ou un changement de direction ?

Et vous, comment abordez-vous la complexité dans vos projets ? Partagez vos expériences, je suis curieux d'échanger !

#DéveloppementLogiciel #Agile #IngénierieSystème #Innovation

Notes

PS : lors de la relecture de cet article, un ami m'a fait part des concepts de Lean Startup ou Chaos Engineering.

Ce que je comprends, c'est que le Lean Startup se concentre principalement sur la validation rapide d'un produit ou d'une idée de business via un MVP, avec un fort accent sur le marché et les utilisateurs. C'est proche de ce que je propose. En revanche, ma proposition intègre des considérations techniques (architecture modulaire, scalabilité), matérielles, et opérationnelles dès la conception pour permettre une bascule rapide et si besoin, une scalabilité plus importante.

J'aime bien le concept de Chaos Engineering, qui teste la résilience en simulant des pannes, m'interpelle, car mes démos ont souvent leur lot de surprises façon « Bonaldi » (soupirs). Je compte l'intégrer plus systématiquement pour renforcer la robustesse de mes systèmes.

Références

[1] - code bas niveau en Verilog pour du hardware jusqu'à des solutions SaaS modernes avec des interfaces en VueJS ou React, en passant par des applications dédiées à l'IA avec Python et PyTorch ou des optimisations en assembleur x64, arm, riscv ou sparcv7 et en Vulkan de moteurs d'inférence LLM.