Réflexions
Pourquoi je crois aux outils open-source
Partager des outils, rendre les systèmes compréhensibles et construire sur des fondations communes.
J’ai toujours aimé comprendre comment les choses fonctionnent.
En biologie, cette curiosité m’a conduite à observer des systèmes complexes et à chercher les mécanismes qui les relient.
En développement logiciel, elle a pris une autre forme.
Comprendre une architecture. Explorer un code. Identifier une dépendance. Construire une solution, puis la tester pour voir si elle fonctionne réellement.
Ce que j’apprécie particulièrement dans le logiciel, c’est cette possibilité de passer d’une idée à quelque chose de concret.
Et de pouvoir ensuite l’améliorer, le partager ou le faire évoluer.
C’est l’une des raisons pour lesquelles je m’intéresse aujourd’hui davantage à l’open source.
01
Nous reconstruisons trop souvent les mêmes choses
Dans les entreprises qui développent des logiciels réglementés, certaines difficultés reviennent régulièrement.
Relier les exigences aux tests.
Maintenir la traçabilité entre les décisions de conception et les preuves de vérification.
Identifier les éléments manquants avant une livraison.
Comprendre les conséquences d’une modification.
Ces besoins ne sont pas nouveaux.
Pourtant, les équipes doivent souvent reconstruire leurs propres méthodes, leurs fichiers de suivi et leurs intégrations.
Parfois parce que leurs outils ne communiquent pas.
Parfois parce que les solutions existantes sont trop complexes ou insuffisamment adaptées à leurs pratiques.
Et parfois simplement parce qu’il manque des composants accessibles, documentés et faciles à intégrer.
Je trouve dommage que tant d’énergie soit consacrée à résoudre plusieurs fois les mêmes problèmes techniques.
02
Ouvrir le code, c’est aussi rendre les choix visibles
L’open source est souvent présenté comme une manière de rendre les logiciels accessibles gratuitement.
C’est une partie de son intérêt, mais ce n’est pas celle qui me semble la plus importante.
Ce que j’apprécie dans une approche ouverte, c’est la possibilité de comprendre comment une solution fonctionne.
D’examiner son architecture.
De voir quelles hypothèses ont guidé sa conception.
De l’adapter à un contexte particulier.
Et éventuellement de contribuer à son amélioration.
Dans les environnements réglementés, cette transparence présente un intérêt particulier.
Les entreprises doivent comprendre les outils qu’elles utilisent, évaluer leurs limites et maîtriser les risques associés à leur intégration.
L’accès au code source ne suffit évidemment pas à garantir la qualité, la sécurité ou la conformité d’un logiciel.
Mais il peut faciliter l’analyse, l’auditabilité et la compréhension des choix techniques.
À condition que le projet soit correctement documenté, maintenu et accompagné de pratiques de développement rigoureuses.
03
Construire des composants plutôt que des systèmes fermés
C’est l’une des idées qui guide mon travail autour de QARAWORK.
Je m’intéresse à la possibilité de développer des outils capables de s’intégrer aux environnements que les équipes utilisent déjà.
Plutôt que d’imposer systématiquement une nouvelle plateforme, pourquoi ne pas permettre à certains outils existants de mieux communiquer ?
Pourquoi ne pas rendre plus accessible la vérification des liens entre exigences et tests ?
Pourquoi ne pas proposer des composants que les développeurs peuvent comprendre, adapter et intégrer à leurs propres processus ?
Cette approche ne répond pas à tous les besoins.
Certaines organisations ont besoin de plateformes complètes, avec des fonctions de gouvernance, de validation et de gestion documentaire.
Mais je crois qu’il existe aussi une place pour des outils plus ciblés, capables de résoudre correctement un problème précis.
Des composants simples dans leur utilisation, même lorsque les enjeux techniques qu’ils adressent sont complexes.
04
L’ouverture n’exclut pas l’exigence
Développer un outil open source destiné à des équipes travaillant dans des environnements réglementés implique des responsabilités.
Il faut être clair sur ce que l’outil fait et sur ce qu’il ne fait pas.
Documenter ses conditions d’utilisation.
Gérer les dépendances et les vulnérabilités.
Définir les modalités de contribution.
Et éviter toute ambiguïté entre un outil qui facilite certaines activités de conformité et un outil dont l’utilisation garantirait automatiquement la conformité d’un produit.
Cette distinction est fondamentale.
Un outil de traçabilité peut aider à identifier des exigences non reliées à des tests.
Il ne peut pas, à lui seul, démontrer que ces tests sont suffisants ou que le dispositif médical est conforme.
L’outil apporte une capacité technique.
L’organisation reste responsable de son utilisation, de sa validation lorsqu’elle est requise et des décisions prises à partir de ses résultats.
Je crois que cette transparence fait partie de la qualité d’un projet open source.
05
Partager pour permettre à d’autres de construire
Il y a aussi une dimension plus personnelle dans cette démarche.
J’ai bénéficié, tout au long de mon parcours dans le logiciel, de connaissances, de bibliothèques et d’outils développés par d’autres.
Cette culture du partage a profondément contribué à ma manière d’apprendre et de construire.
Aujourd’hui, j’ai envie d’y contribuer à mon tour.
Pas nécessairement en développant des solutions gigantesques.
Mais en mettant à disposition des composants utiles, suffisamment compréhensibles pour être repris et suffisamment ouverts pour évoluer au-delà de leur conception initiale.
Je trouve cette perspective particulièrement intéressante dans la santé, où les enjeux de sécurité et de qualité sont élevés et où les équipes ont besoin de solutions fiables.
Je ne crois pas que chaque entreprise doive réinventer ses fondations techniques pour pouvoir innover.
Je crois davantage à des outils que l’on peut comprendre, questionner, améliorer et faire évoluer collectivement.
C’est cette philosophie que j’ai envie d’explorer avec QARAWORK.
Construire des outils utiles, les partager et permettre à d’autres d’aller plus loin avec eux.
