Quand j'ai été invitée à intervenir à Belgium RSE 2024, j'avais en tête une théorie que je voulais partager et discuter avec d'autres. Elle porte sur la façon dont les logiciels naissent dans les laboratoires académiques.
Ces cinq dernières années, j'ai eu l'occasion de travailler avec plusieurs labos et d'échanger avec beaucoup d'autres. Un schéma récurrent s'est dessiné, une histoire familière sur l'origine des logiciels dans ces environnements. Souvent, tout commence par un projet annexe mené par un doctorant, un postdoc, ou parfois même par le ou la responsable du labo.
En général, tout part d'une personne passionnée de programmation qui voit l'occasion de simplifier ou d'améliorer son propre travail. Une fois que l'outil a fait ses preuves, il ne tarde pas à se répandre dans le labo, et d'autres l'adoptent pour leurs projets.
Au début, tout le monde est content. L'outil fonctionne bien et le labo profite de son efficacité. Mais très vite, toute la responsabilité retombe sur la personne qui l'a écrit. On attend d'elle qu'elle s'occupe de tout : maintenir le logiciel, développer de nouvelles fonctionnalités, corriger les bugs, dépanner, et même aider à l'installer sur d'autres machines.
Ce qui n'était qu'un projet annexe devient soudain un travail à plein temps, sans le temps ni le financement nécessaires. Pour répondre à des demandes toujours plus nombreuses, le développeur multiplie souvent les corrections rapides, au détriment des bonnes pratiques et de la maintenabilité à long terme.
À ce stade, on peut dire qu'un projet logiciel est vraiment né. Deux scénarios s'ensuivent en général.
Dans le premier, une équipe dédiée se forme pour travailler à plein temps sur le projet. C'est souvent le cas des initiatives qui réussissent et disposent d'un soutien important, comme DeepLabCut, SpikeInterface ou Open-Ephys. Ces projets bénéficient de ressources, d'une organisation et d'une pérennité à long terme.
Dans le second, la responsabilité reste entre les mains d'une seule personne, et les difficultés arrivent. Le logiciel peut se fragmenter en plusieurs versions divergentes, chacune adaptée à certains utilisateurs mais difficiles à réconcilier. Les utilisateurs aimeraient réunir ces versions en un seul outil cohérent, mais l'effort est souvent trop grand. Ou bien la personne qui le maintient s'en va, et avec elle la connaissance nécessaire pour le faire vivre : le projet est abandonné et devient inutilisable.
Ces derniers temps, j'interviens justement en freelance à ce stade précis : quand le logiciel s'est éclaté en versions impossibles à réconcilier, et que plus personne ne sait vraiment comment avancer. C'est un défi que j'aime relever, et je suis devenue efficace pour diagnostiquer et régler rapidement ces problèmes.
Si cette histoire vous parle et que vous êtes dans une situation semblable, n'hésitez pas à me contacter. Je peux vous aider à retrouver un logiciel qui fonctionne sans accroc, avec la simplicité et l'efficacité qui faisaient le bonheur de tous, pour que votre équipe se concentre à nouveau sur sa recherche.