BLOGUE – Dans mes deux précédents billets*, j’ai discuté de la notion de gouvernance informatique et de ses implications stratégiques. Le choix des technologies, entre autres, repose sur plusieurs éléments : l’application est-elle compatible avec l’existant? Quelles sont les évolutions qui sont envisagées dans le futur – infonuagique, intégration continue, agilité? La solution sera-t-elle compatible avec ces évolutions et à quels coûts?
Une fois que ces critères ont été déterminés, la sélection de l’application sur une base de fonctionnalités commence. De plus en plus, ce choix comprend des logiciels libres, dont de nombreux sont de nature communautaire, c’est-à-dire sans éditeur adossé. Nous voilà donc face à un dilemme : comment peut-on profiter des avantages du logiciel libre en minimisant le risque? En d’autres mots : quelle est la meilleure stratégie en matière de gouvernance d’un logiciel libre?
Mise en place d’une gouvernance simple : l’approche DILEC
La gouvernance d’un logiciel libre communautaire peut se résumer en un simple acronyme, soit « DILEC » :
- Discuter – ouvrir le dialogue avec la communauté, poser des questions
- S’Impliquer – être présent et apporter de nouvelles perspectives
- Libérer son code – reverser ses contributions
- Escorter – permettre l’utilisation du code via la documentation
- Communiquer – maintenir le dialogue
Pour éclaircir ces différents points, je vous suggère de lire ce témoignage de Sébastien Coavoux, un professionnel du logiciel libre, qui explique comment il a travaillé à l’intégration de l’outil de supervision Shinken au sein d’une grande société publique du Québec.
Discuter
« La première étape du processus a été la réalisation d’une preuve de concept. La preuve
de concept est une étape primordiale dans l’utilisation de la solution. De façon générale, elle est intéressante dans le domaine de l’open source, car elle permet les premiers contacts avec la communauté.
« En effet, lors de la prise en main d’une solution par des intégrateurs, le premier réflexe est de se tourner vers la documentation pour trouver de l’aide. Malheureusement, elle peut être incomplète, ce qui était vrai dans notre cas. Les intégrateurs se sont alors tournés alors vers les moyens de communication pour avoir de l’aide de la communauté : listes de diffusions, IRC, site du projet… Le contact était ainsi établi. »
S’impliquer
« La preuve de concept a permis d’en faire davantage, soit la remontée et la correction de défauts de programmation dans le logiciel. C’est un nouveau pas vers la communauté pour les intégrateurs et de facto un bénéfice pour le logiciel.
« La présence a aussi été un avantage pour la société voulant utiliser Shinken : c’est un moyen de s’assurer une certaine pérennité de la solution. L’ajout de fonctionnalité ou correction de bogue permet d’alimenter le projet et, dans le cas de cet exemple, le stabiliser. »
Libérer son code
« Mais pour que le projet soit alimenté, il faut que les sources soient réversibles et reversées. Certaines modifications ne peuvent pas s’ajouter à la base de code existante, car elles sont trop spécifiques. Il faut alors trouver une façon de rendre ces contributions profitables à tout le monde », note Sébastien Coavoux.
« Le processus peut être long, mais il vaut la peine, car maintenir un patch non appliqué dans les sources du projet est souvent beaucoup plus couteux qu’on peut l’imaginer.
« Le cas étudié ici permet d’autres contributions que simplement du code. Le domaine d’utilisation du logiciel – la supervision – permet un partage de connaissances : par exemple, la manière de superviser d’un équipement spécifique. Les sondes de supervision ainsi que leurs configurations sont partageables avec quelques précautions, comme la suppression d’identifiants clients. »
Escorter
« Cependant, ces contributions spécifiques impliquent un accompagnement. Les sondes de supervision représentent la technique à l’état pur. Il est souvent difficile d’utiliser une sonde sans avoir de connaissances techniques préalables. Or, ces contributions doivent être maitrisées à un minimum par l’utilisateur pour en profiter, car ce sont des outils. La problématique ici est de faciliter l’apprentissage de ces contributions et de faciliter l’accès.
« Une solution qui facilite l’apprentissage est la réalisation d’une documentation. Concernant l’accessibilité, la solution qui semble meilleure est la mise à disposition de paquets pour différentes distributions Linux. Une installation par un système de gestionnaire de paquets est toujours préférable à une installation manuelle. »
Communiquer
« Vient alors le temps de la communication sur les contributions et de l’implication dans le logiciel. Elle permet de mettre en avant les nouveautés du logiciel et donc son activité. De cette mise en avant peut résulter de nouveaux utilisateurs du logiciel. Enfin, d’un point de vue la société contributrice, il est évident que cela est un retour positif », conclut Sébastien Coavoux.
Prêt pour le futur?
Le témoignage de Sébastien est moderne en beaucoup de points – c’est normal, puisque Sébastien a 25 ans. Les notions d’agilité, d’ouverture et d’échange sont naturelles pour sa génération… Pourtant, ce modèle est au fondement de l’informatique depuis les années 60.
Voilà donc un élément supplémentaire dans votre décision en faveur des logiciels libres : attirer au sein de votre organisation les fameuses générations Y et Z.
Et vous, êtes-vous prêt pour le futur ?
* Lire les billets Gouvernance SI : structure d’appui ou pilier de la compétitivité? – première partie et deuxième partie