TL;DR : avec un logiciel libre, personne ne vous facture le droit de l'utiliser, mais personne ne décide non plus à votre place quand le mettre à jour, qui appeler quand il casse ou comment en sortir. Une implantation qui dure se joue sur sept décisions prises avant d'installer : un budget qui paie des personnes plutôt qu'une licence, un projet vivant, une licence lue jusqu'au bout, un cœur jamais modifié, des versions inscrites au calendrier, des accès qui restent chez vous et une sortie testée avant l'entrée. La Loi 25 en impose d'ailleurs une partie dès qu'il y a des renseignements personnels dans le système.
Dans cet article
- Budgéter des personnes plutôt qu'une licence : le code ne coûte rien, mais l'hébergement, le soutien, la formation et la prochaine version majeure doivent avoir leur ligne au budget.
- Choisir un projet vivant, pas seulement une liste de fonctions : cinq questions sur les mainteneurs, les versions, les avis de sécurité, les droits et le soutien, l'affaire xz Utils en exemple.
- Lire la licence, et vérifier qui peut la changer : les obligations d'usage sont légères, mais une entreprise seule propriétaire du code peut changer la licence, comme Terraform et Redis.
- Configurer avant de personnaliser, et ne jamais toucher au cœur : changer de méthode, configurer, ajouter un module de l'OCA ou développer à côté, mais jamais modifier le code d'origine.
- Mettre les versions au calendrier dès le premier jour : Odoo soutient chaque version trois ans et Nextcloud un an, des échéances connues à inscrire au calendrier dès l'installation.
- Savoir qui appeler, et garder les clés chez vous : le soutien d'Odoo est réservé à Enterprise, et le compte administrateur, les sauvegardes et la documentation doivent rester chez vous.
- Prévoir la sortie avant d'entrer : une exportation testée avant la mise en service, et la Loi 25 qui exige une EFVP et un format structuré.
- Ce que le libre ne règle pas : un processus confus reste confus, certains besoins de niche n'ont pas d'équivalent libre et il faut une compétence quelque part.
- Comment on s'y prend : configurer avant de développer, des modules publiés sous licence libre, et des accès qui restent à l'organisation.
Le serveur a été installé un vendredi après-midi par quelqu'un qui s'y connaissait. Trois ans plus tard, il tourne toujours. Personne ne sait plus dans quelle version, la personne qui l'a monté est partie, et le mot de passe d'administration dort dans un courriel que personne ne retrouve. Le jour où une faille est annoncée, la question n'est pas « faut-il corriger? », c'est « qui peut seulement se connecter? ».
Le logiciel n'y est pour rien. Ce qui a manqué, ce sont des décisions qu'un éditeur propriétaire prend d'habitude à votre place, pour le meilleur et pour le pire : quand passer à la version suivante, qui répond au téléphone, sous quelles conditions vous pouvez repartir avec vos données. Avec un logiciel libre, ces décisions vous reviennent. C'est tout l'intérêt du libre. C'est aussi là que bien des implantations déraillent.
Le volet humain d'un changement de système (l'adhésion, la résistance, les super-utilisateurs, la période de stabilisation) est couvert dans notre article sur les stratégies pour réussir l'implantation d'un ERP en PME. Ici, on s'en tient à ce qui est propre au libre.
Pour garder l'essentiel sous la main, les sept décisions tiennent sur une page à imprimer : l'aide-mémoire « Implanter un logiciel libre » en PDF.
Budgéter des personnes plutôt qu'une licence
La première erreur se fait dans le tableur, avant même de choisir l'outil : inscrire « 0 $ » sur la ligne du logiciel et s'arrêter là. Le code ne coûte rien à télécharger. Le faire tourner, le garder à jour, former les gens et répondre quand quelque chose bloque : tout ça se paie.
La différence avec un abonnement propriétaire ne tient pas au montant total, qui peut être comparable la première année. Elle tient à ce que l'argent achète. Une licence achète le droit d'utiliser, renouvelé chaque année tant que vous payez. Avec le libre, le même budget paie de l'hébergement, du soutien et de la compétence : des choses que vous pouvez changer de fournisseur sans perdre le logiciel, et qui restent souvent dans l'économie d'ici.
Concrètement, un budget réaliste prévoit quatre lignes : l'hébergement (ou le temps de la personne qui s'en occupe à l'interne), la mise en place et la migration des données, le soutien courant et la formation, puis une réserve pour la prochaine version majeure. Cette dernière ligne est celle qu'on oublie, et on y revient plus bas. Pour des chiffres sur cinq ans, notre calcul comparatif entre Microsoft 365 et une pile libre fait l'exercice ligne par ligne.
Choisir un projet vivant, pas seulement une liste de fonctions
Deux logiciels libres peuvent cocher exactement les mêmes cases dans un comparatif et n'avoir rien en commun sur la durée. L'un est porté par une fondation, une entreprise qui en vit et des centaines de contributeurs. L'autre est le projet du soir d'une seule personne, brillant, mais sans relève. Le second peut très bien convenir pour un petit utilitaire. Pour votre facturation ou vos dossiers clients, c'est un pari.
Le risque n'est pas théorique. Le 29 mars 2024, un ingénieur qui cherchait pourquoi ses connexions SSH consommaient trop de processeur a découvert une porte dérobée dans xz Utils, une petite bibliothèque de compression présente dans la plupart des distributions Linux. Le projet était bénévole, et son mainteneur avait écrit sur la liste du projet, en 2022, que sa capacité à s'en occuper était « assez limitée ». Les versions piégées avaient été signées par un contributeur devenu co-mainteneur au fil du temps. L'affaire a montré à tout le monde ce que vaut un composant critique dont la relève tient à une seule personne.
Avant de choisir, quelques questions suffisent, et elles se posent sans être informaticien :
| La question | Pourquoi elle compte | Où trouver la réponse |
|---|---|---|
| Qui maintient le projet, et combien sont-ils? | Un mainteneur unique est un point de rupture, qu'il parte ou qu'il s'épuise. | La page de gouvernance du projet, la liste des contributeurs du dépôt de code. |
| À quel rythme sortent les versions? | Un projet sans version depuis plus d'un an est peut-être à l'abandon. | La page des versions (« releases ») ou le journal des modifications. |
| Où sont publiés les avis de sécurité? | Sans avis publics, impossible de savoir ce qu'il faut corriger, ni quand. | Une page « Security » ou un registre d'avis sur le dépôt. |
| Qui détient les droits sur le code? | C'est ce qui détermine qui peut, un jour, changer la licence. | Le fichier de licence, la fondation ou l'entreprise derrière le projet, l'accord demandé aux contributeurs. |
| Peut-on acheter du soutien, idéalement près de chez vous? | Quelqu'un doit répondre un lundi matin, en français si possible. | L'annuaire des partenaires de l'éditeur, les intégrateurs de votre région. |
Pour aller plus loin, il existe des outils qui mesurent ces signaux de façon systématique : les métriques de santé de communauté du projet CHAOSS, ou le tableau de bord OpenSSF Scorecard, qui note les pratiques de sécurité d'un dépôt. Votre fournisseur devrait pouvoir vous en montrer le résultat pour les outils qu'il vous propose.
Et la santé d'un projet, ça s'entretient aussi de votre côté. Signaler un bogue proprement, traduire une page, payer une adhésion à l'association qui fédère les contributeurs : c'est la prime d'assurance la moins chère qui soit sur un outil dont vous dépendez. Le gouvernement fédéral le demande d'ailleurs à ses propres ministères : sa Directive sur les services et le numérique leur demande d'encourager le logiciel libre et de contribuer aux communautés dont ils utilisent le travail. On en a parlé dans notre article sur le logiciel libre et le mutualisme et dans celui sur les modèles de contribution des projets open source.
Lire la licence, et vérifier qui peut la changer
Pour une organisation qui utilise un logiciel libre sans le revendre, la plupart des licences posent très peu d'obligations. Les licences dites permissives (MIT, Apache) n'en posent presque aucune. Les licences à réciprocité (GPL, AGPL, LGPL) en posent surtout quand vous modifiez le code et que vous le distribuez, ou, pour l'AGPL, que vous faites utiliser une version modifiée à travers le réseau. Utiliser Nextcloud (AGPLv3) ou Odoo Community (LGPLv3) pour vos propres équipes ne vous oblige pas à publier vos données ni vos réglages.
Deux pièges méritent par contre qu'on s'y arrête.
Le modèle « open core »
Plusieurs projets ont une version libre et une version commerciale, où se trouvent certaines fonctions. C'est un modèle légitime. Il finance souvent le projet libre lui-même. Il faut seulement savoir, avant de signer, de quel côté de la ligne tombent les fonctions dont vous avez besoin. Odoo en est l'exemple le plus connu, et notre article sur Odoo Community et Odoo Enterprise détaille la frontière.
La licence qui change en cours de route
Quand une seule entreprise détient tous les droits sur le code, elle peut décider de changer la licence des versions futures. C'est arrivé à des projets très connus. En août 2023, HashiCorp a fait passer Terraform d'une licence libre (MPL 2.0) à la Business Source License, dont le texte précise lui-même qu'elle n'est pas une licence open source. Elastic avait fait le même genre de virage en janvier 2021, et Redis l'a fait en mars 2024.
Les versions déjà publiées, elles, restent disponibles sous l'ancienne licence. La communauté a donc pu repartir de la dernière version libre : OpenTofu pour Terraform, Valkey pour Redis, tous deux sous l'égide de la Linux Foundation. Et Elastic en 2024, puis Redis en 2025, ont fini par ajouter une licence libre, l'AGPL, à côté des autres. Le libre ne vous protège pas d'un changement de cap de l'éditeur. Il vous laisse par contre une porte de sortie : la dernière version libre, que n'importe qui peut reprendre.
La pratique qui en découle est simple : préférez les projets dont les droits sont répartis entre de nombreux contributeurs ou confiés à une fondation, et, si l'outil est porté par une seule entreprise, sachez d'avance s'il existe une communauté capable de reprendre le flambeau. C'est d'ailleurs la raison d'être affichée de l'OCA : faire en sorte qu'Odoo reste un ERP libre viable, quoi que décide un jour l'éditeur.
Configurer avant de personnaliser, et ne jamais toucher au cœur
Avoir le code source, c'est avoir le droit de tout modifier. C'est aussi la tentation la plus coûteuse du libre. Chaque modification faite directement dans le code d'origine devra être refaite, vérifiée et testée à chaque nouvelle version, par quelqu'un qui comprend pourquoi elle existe. Au bout de deux ou trois versions, plus personne n'ose mettre à jour. Vous voilà avec un logiciel figé, comme un vieux système propriétaire, la licence en moins.
L'ordre des solutions, du moins cher au plus cher à entretenir :
- Changer la façon de travailler pour suivre le logiciel, quand l'écart est petit et que le processus actuel n'a rien de particulier.
- Configurer : champs, étapes, droits, modèles de documents. Tout ce qui se règle à l'écran survit aux versions.
- Ajouter un module existant, maintenu par une communauté. Dans l'univers d'Odoo, c'est le rôle de l'Odoo Community Association (OCA), qui publie des milliers de modules sous licence libre et outille leur migration d'une version à l'autre.
- Développer un module à vous, à côté du code d'origine, jamais dedans, et idéalement publié sous licence libre pour que d'autres puissent le maintenir avec vous.
La modification directe du cœur n'est pas sur la liste. Si quelqu'un vous la propose, demandez qui la refera à la prochaine version, et combien ça coûtera.
Mettre les versions au calendrier dès le premier jour
Un logiciel propriétaire en abonnement se met à jour tout seul, que vous soyez prêts ou non. Un logiciel libre installé chez vous attend qu'on le fasse. Les deux ont leurs défauts, mais le second a un piège particulier : rien ne vous oblige à bouger, jusqu'au jour où la version que vous utilisez ne reçoit plus de correctifs de sécurité.
Les projets sérieux publient ce calendrier d'avance. Odoo sort une version majeure par année (la 20 est arrivée en septembre 2026) et soutient chacune pendant trois ans. Ces trois ans courent à partir de la sortie, pas de votre installation : installer la 18 aujourd'hui, c'est prévoir une migration dans moins d'un an. Nextcloud sort trois versions majeures par année, et chacune reçoit des correctifs pendant un an dans sa version communautaire. L'abonnement Enterprise de l'éditeur allonge ce soutien. Ce ne sont pas des surprises : ce sont des échéances connues le jour de l'installation.
La pratique consiste donc à traiter les mises à jour comme un poste du budget, pas comme un imprévu :
- les correctifs de sécurité (versions mineures) s'appliquent vite, en continu, par une personne nommément responsable qui suit les avis de sécurité du projet
- les versions majeures se planifient une fois par cycle, avec une copie de la base pour tester avant de basculer
- la date de fin de soutien de chaque logiciel installé est inscrite quelque part où quelqu'un la verra passer.
Le Centre canadien pour la cybersécurité en fait la deuxième de ses dix mesures de sécurité des TI : dès qu'un correctif de sécurité est publié, il demande de l'appliquer « le plus rapidement possible ». Avec le libre, c'est vous qui tenez cette mesure, ou la personne à qui vous la confiez par écrit.
Savoir qui appeler, et garder les clés chez vous
Avec un logiciel libre, le soutien ne vient pas avec la licence, puisqu'il n'y en a pas à payer. Chez Odoo par exemple, le soutien fonctionnel de l'éditeur et son service de mise à niveau sont réservés aux abonnés Enterprise, qui reçoivent aussi les avis de sécurité en privé avant leur publication. En Community, le soutien vient d'un intégrateur, d'un consultant ou de votre propre équipe. Ce n'est pas un défaut, c'est un choix à faire consciemment, et par écrit : qui répond, dans quel délai, pour quels types de problèmes, et à quel prix.
Mais le vrai piège est ailleurs. Le libre vous libère de l'éditeur. Il ne vous libère pas automatiquement de votre fournisseur. Si c'est l'intégrateur qui détient le seul accès administrateur, qui fait les sauvegardes sur ses propres serveurs et qui a des modifications non documentées dans son coin, vous avez remplacé une dépendance par une autre, sans contrat de licence pour la baliser.
Quelques exigences raisonnables, à poser dès le départ :
- un compte administrateur au nom de l'organisation, dont le mot de passe vit dans votre coffre, pas seulement dans celui du fournisseur
- des sauvegardes dont vous détenez une copie, et dont la restauration a été testée au moins une fois
- une documentation de l'installation : versions, modules ajoutés, réglages particuliers, comptes techniques
- le code de tout développement fait pour vous, avec le droit de le confier à quelqu'un d'autre.
Un bon fournisseur accepte tout ça sans discuter. Celui qui hésite vous dit quelque chose d'important sur la relation.
Prévoir la sortie avant d'entrer
On ne choisit pas un logiciel en pensant au jour où on le quittera. C'est pourtant le meilleur moment pour y penser, parce que c'est le seul où vous avez encore tout le pouvoir de négociation.
Le libre part avec une longueur d'avance : formats ouverts et documentés, bases de données standard, et le droit de faire tourner le même logiciel ailleurs. Mais une porte de sortie, ça se vérifie. Avant la mise en service, demandez une exportation complète d'un jeu de données réel, ouvrez-la avec autre chose que l'outil d'origine, et regardez ce qui manque : les pièces jointes, l'historique, les liens entre les fiches.
Au Québec, une partie de cette réflexion n'est plus optionnelle. Depuis septembre 2023, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée pour tout projet d'acquisition, de développement ou de refonte d'un système d'information qui touche des renseignements personnels, avec le responsable de la protection des renseignements personnels consulté dès le début. Et le même article demande que le système permette de remettre à une personne les renseignements qu'elle vous a fournis, dans un format technologique structuré et couramment utilisé. Un logiciel dont vous ne savez pas sortir les données ne passe pas ce test.
L'évaluation doit être proportionnée à la sensibilité et à la quantité des renseignements : un petit système demande une petite évaluation, et la Commission d'accès à l'information publie un guide d'accompagnement pour la mener. La même Commission précise que la loi peut aussi viser un OBNL, selon une analyse au cas par cas de ses activités.
Pour savoir par où commencer quand plusieurs outils sont en jeu, l'ordre proposé dans notre article sur ce qui reste debout quand le nuage américain ferme tient toujours : le coffre de mots de passe, puis les fichiers, puis le cœur d'affaires, et l'identité en dernier.
Avant de signer avec qui que ce soit pour implanter un logiciel libre, demandez à voir :
- la version qu'on vous installe et sa date de fin de soutien
- le compte administrateur au nom de votre organisation, et où dort son mot de passe
- une sauvegarde restaurée, et une exportation complète ouverte hors de l'outil
- la liste des modules ajoutés, et toute modification faite au code d'origine (idéalement aucune)
- le délai de réponse écrit pour un incident, et le nom de la personne qui suit les avis de sécurité.
Ce que le libre ne règle pas
Un logiciel libre n'améliore pas un processus mal pensé. Il le reproduit fidèlement, souvent plus vite. Si la facturation est confuse aujourd'hui, elle le sera dans le nouvel outil. Le changement de système devient alors l'occasion de blâmer le logiciel plutôt que de corriger le processus.
Il ne couvre pas non plus tous les besoins. Certains logiciels de niche, propres à un secteur ou à une réglementation, n'ont pas d'équivalent libre mûr. Une pile cohérente peut très bien compter une ou deux pièces propriétaires, à condition de savoir lesquelles et de garder les données qu'elles contiennent récupérables.
Il demande enfin une compétence qu'un abonnement vous épargne. Quelqu'un, à l'interne ou chez un fournisseur, doit comprendre l'installation assez bien pour la faire évoluer. Si cette compétence n'existe nulle part, l'économie de licence se paiera plus tard, en urgence. Et quand quelque chose casse, il n'y a pas de grand éditeur à blâmer : la responsabilité est partagée entre vous et ceux que vous avez choisis. C'est le prix de la liberté de choisir. Mieux vaut le connaître avant de signer.
Comment on s'y prend
Notre approche suit cet ordre-là. On commence par le processus et par les données, on configure avant de développer, et ce qu'on développe vit dans des modules séparés, publiés sous licence libre, comme nos modules Odoo maison sur GitHub. Le calendrier des versions fait partie de l'entente dès le départ, et l'organisation garde ses accès administrateur, ses sauvegardes et la documentation de son installation.
Notre préférence va aux outils libres hébergés au Québec, sous le contrôle de l'organisation. La raison est pratique. C'est la seule façon de répondre clairement aux trois questions qui reviennent toujours : où vivent les données, qui peut les lire et comment on en sort.
Explorons votre projet ensemble, que vous partiez de zéro ou d'une installation dont plus personne ne connaît la version.
Sources
- Odoo, documentation sur la mise à niveau : chaque version majeure est prise en charge pendant trois ans, et la mise à niveau est gratuite avec Odoo Enterprise.
- Odoo, assistance standard et étendue (en anglais) : le calendrier par version : la 20 sortie en septembre 2026, la 18 soutenue jusqu'en septembre 2027.
- Odoo, comparaison des éditions : le support fonctionnel illimité et les mises à jour de version cochés pour Enterprise seulement.
- Odoo, signalement des failles de sécurité (en anglais) : les avis et correctifs transmis en privé aux clients Enterprise avant leur divulgation publique.
- Odoo, fichier de licence de la version 20.0 (en anglais) : Odoo Community publié sous LGPLv3.
- Nextcloud Server, fichier de licence (en anglais) : le serveur publié sous AGPLv3.
- Nextcloud, calendrier de maintenance des versions (en anglais) : une version majeure tous les quatre mois, soutenue un an par des versions de maintenance mensuelles.
- Nextcloud, tarifs de l'abonnement Enterprise : un cycle de maintenance d'un an au forfait Standard, de cinq ans et plus aux forfaits supérieurs.
- Andres Freund, message sur la liste oss-security du 29 mars 2024 (en anglais) : la découverte de la porte dérobée de xz Utils à partir de connexions SSH trop gourmandes.
- Lasse Collin, message sur la liste xz-devel du 8 juin 2022 (en anglais) : le mainteneur décrit sa capacité limitée et un projet de loisir non rémunéré.
- Projet Tukaani, page sur la porte dérobée de xz (en anglais) : les versions 5.6.0 et 5.6.1 piégées, créées et signées par le co-mainteneur Jia Tan.
- CHAOSS, présentation du projet (en anglais) : un projet de la Linux Foundation qui produit des métriques de santé des communautés open source.
- OpenSSF Scorecard (en anglais) : des vérifications automatisées qui notent sur 10 les risques de sécurité d'un projet open source.
- HashiCorp, annonce du 10 août 2023 (en anglais) : le passage de la MPL 2.0 à la Business Source License 1.1 pour les versions futures.
- Texte de la Business Source License 1.1 (en anglais) : la licence précise elle-même qu'elle n'est pas une licence open source.
- Elastic, annonce du 14 janvier 2021 (en anglais) : Elasticsearch et Kibana passent d'Apache 2.0 à SSPL et Elastic License.
- Elastic, annonce du 29 août 2024 (en anglais) : l'AGPL ajoutée comme option de licence à côté des deux autres.
- Redis, annonce du 20 mars 2024 (en anglais) : la fin de la licence BSD à partir de Redis 7.4.
- Redis, annonce du 1er mai 2025 (en anglais) : l'AGPLv3 ajoutée comme option de licence à partir de Redis 8.
- Linux Foundation, annonce d'OpenTofu du 20 septembre 2023 (en anglais) : le successeur libre de Terraform sous MPL 2.0.
- Linux Foundation, annonce de Valkey du 28 mars 2024 (en anglais) : le développement repris à partir de Redis 7.2.4, sous licence BSD.
- Odoo Community Association (en anglais) : des milliers de modules sous licences libres, et la mission de garder Odoo viable comme ERP libre quoi que décide Odoo S.A.
- Loi sur la protection des renseignements personnels dans le secteur privé, article 3.3 : l'évaluation des facteurs relatifs à la vie privée, la consultation du responsable dès le début du projet et le format technologique structuré, en vigueur depuis le 22 septembre 2023.
- Commission d'accès à l'information, champ d'application de la loi : la loi peut viser un OBNL, selon une analyse au cas par cas.
- Commission d'accès à l'information, guide d'accompagnement de l'EFVP (version 3.1, avril 2024) : la démarche et sa documentation.
- Centre canadien pour la cybersécurité, les 10 mesures de sécurité des TI (ITSM.10.089) : mesure 2, appliquer des correctifs aux applications et aux systèmes d'exploitation.
- Secrétariat du Conseil du Trésor du Canada, Directive sur les services et le numérique : article 4.3.22, encourager les logiciels libres et contribuer aux collectivités dont le travail est exploité.