Quand un dirigeant me demande pourquoi je travaille avec des outils libres, il s'attend souvent à un discours militant. Il n'en aura pas. La réponse à « pourquoi open source en entreprise » est plus simple, et plus honnête : l'open source m'a permis d'apprendre, de travailler, et de proposer à mes clients des solutions qu'ils peuvent garder. En contrepartie, ça demande un peu plus de temps de configuration. Voilà l'arbitrage — pas un dogme, un calcul. Cet article expose pourquoi je fais ce choix, ce que ça coûte vraiment, ce que ça offre en échange, et le critère qui devrait vous aider à trancher pour vos propres outils.
L'open source n'est pas magique. Il a un coût. Mais ce n'est pas celui qu'on croit.
— Mattieu Pottier, MP-i
Pourquoi j'ai choisi l'open source
Apprendre et travailler sans budget licences
e point de départ est trivial : très tôt dans mon parcours, je n'avais pas les moyens d'aligner les licences propriétaires que mes études et mes premiers projets exigeaient. La 3D, le SIG, la PAO, le développement — chacun de ces univers se vendait à plusieurs milliers d'euros par an. Pour un étudiant, puis pour un freelance qui démarre, c'était hors de portée.
À cette époque, beaucoup contournaient le problème en piratant les outils propriétaires. Je n'ai jamais voulu prendre ce chemin, et je le voulais d'autant moins en devenant professionnel : un freelance qui livre des outils crackés expose son client à un risque juridique réel et perd toute crédibilité au premier audit.
Quand on travaille sérieusement, on ne s'installe pas sur des fondations illégales. La bonne nouvelle, c'est qu'il n'y a quasiment jamais de raison de le faire — il existe presque toujours une solution open source qui fait le travail, à condition d'accepter d'apprendre.
C'est ce que j'ai fait. GIMP à la place de Photoshop. LibreOffice à la place de la suite Microsoft. QGIS à la place d'ArcGIS. FreeCAD et Blender à la place d'AutoCAD ou de Maya. Linux comme système d'exploitation, Android comme téléphone.
Tous ces outils n'étaient pas équivalents à leurs alternatives propriétaires — ils ne le sont toujours pas sur certains points précis. Mais ils étaient suffisants pour apprendre, pour produire, pour livrer.
Et ce qui s'est passé ensuite, c'est ce que je n'avais pas prévu : à force de vivre avec ces outils, j'en ai compris la logique. La structure d'un fichier QGIS. La façon dont LibreOffice gère ses styles. La manière dont Linux organise un système. Cet apprentissage s'est révélé être un investissement plus profond que la simple substitution d'un produit par un autre — j'ai appris à comprendre les outils, pas seulement à les utiliser.
Livrer des solutions que le client peut garder
Quand je suis passé du statut d'étudiant à celui de professionnel, puis de freelance, la raison de mon choix open source a changé sans que je le décide consciemment. Ce n'était plus une question de budget. C'était devenu une question de livraison.
SIG terrain
Données hébergées en local ou sur VPS, exportables à tout moment. Le client reprend la main sans dépendre d'un prestataire unique.
Bureau d'études
GED, versioning, automatisation des workflows documentaires. Stack open source déployée chez le client.
Plateforme de gestion
CRM, facturation, gestion de projet. Le client garde la main sur ses données et peut changer de prestataire.
Site web
CMS open source avec modules sur-mesure. Code versionné sous Git, hébergement au choix du client.
Quand je livre aujourd'hui une solution chez un client, il repart avec quelque chose qui lui appartient vraiment. Il peut continuer à utiliser l'outil sans moi. Il peut faire intervenir un autre prestataire si je deviens indisponible ou si mon prix ne lui convient plus.
Il peut exporter ses données dans un format documenté, à n'importe quel moment.
Cette continuité change la nature de la relation commerciale. Je ne vends pas une dépendance. Je vends une compétence d'intégration sur des outils que le client possède. La nuance est mince à formuler, mais elle est radicale dans la durée.
Le réflexe du jeune dev — et pourquoi je m'en suis défait
Il y a une étape par laquelle beaucoup de développeurs et de freelances passent au début, et que j'ai traversée comme les autres : le réflexe du full custom. On reçoit une demande client, on évalue le besoin, et on se dit « je vais le coder, ça ira plus vite que de chercher ». C'est tentant — c'est un terrain qu'on maîtrise, c'est valorisant techniquement, et on a l'impression de maîtriser le délai.
À éviter
Full custom
- Coût explose — cas limites, permissions, exports, sauvegardes, admin, doc
- Délai dérape — sujets non anticipés au cadrage
- Maintenance solo pendant cinq ans
Recommandé
Benchmark + OSS mature
- 70-90 % du besoin couvert sans écrire une ligne
- Délai prévisible — on connecte, on adapte, on ajoute la couche métier
- Équipe de centaines de développeurs en arrière-plan, gratuitement
J'ai changé de méthode. La première étape de tout projet est désormais un petit benchmark de ce qui existe sur le marché et qui répond au besoin du client. Même quand je connais déjà des outils du domaine, je le refais à chaque fois — parce que je ne connais pas tout, et parce que les outils évoluent. Et je me rends compte qu'il y a quasiment toujours un ou deux choix open source qui couvrent 70 à 90 % du besoin sans avoir à écrire la première ligne de code. Je n'ai plus qu'à connecter, à adapter, à ajouter la couche métier spécifique au client.
Le gain est massif. Vous ne partez pas de zéro, donc le coût et le délai diminuent dans des proportions que le full custom ne peut pas approcher.
Mais surtout — et c'est l'argument que peu de décideurs entendent formulé clairement :
Aucun freelance solo, aucune ESN raisonnable, aucun éditeur propriétaire de taille moyenne ne peut offrir cette force de frappe permanente. Vous l'obtenez gratuitement en choisissant l'écosystème libre — c'est une mécanique économique simple, mais qui change tout.
Ce que l'open source coûte vraiment
L'honnêteté commande de ne pas s'arrêter là. L'open source a des coûts réels qu'il faut nommer, sinon le récit devient militant et le décideur sérieux décroche.
La configuration prend plus de temps — et c'est logique
Le premier coût est le plus visible : un outil open source demande presque toujours plus de temps à configurer pour un cas d'usage précis qu'un outil propriétaire conçu pour ce cas. Ce n'est pas un défaut. C'est la conséquence directe du modèle de financement.
Un outil libre vit du nombre de cas qu'il sait servir : il est pensé pour mille usages, donc il offre la flexibilité plutôt que la spécialisation. Un outil propriétaire vit de la marge qu'il dégage sur un segment commercial : il pousse la personnalisation à fond sur ce segment, parce que c'est là qu'il vend. Effort de configuration plus élevé d'un côté, prix plus élevé de l'autre — chacun finance son modèle à sa manière.
Concrètement, déployer Odoo Community pour gérer une entreprise prend plus de temps que souscrire à un SaaS ERP propriétaire spécialisé sur le secteur visé. Configurer QGIS pour traiter un cas SIG métier précis prend plus de temps qu'ouvrir un outil propriétaire calibré sur ce cas. Ce temps n'est pas perdu — il est absorbé dans la configuration de l'outil libre — mais il est bien là, et il faut l'anticiper.
Une précision pour situer correctement cet arbitrage : plus rapide qu'un développement from scratch, plus lent qu'un SaaS calibré sur votre cas exact — l'open source occupe le milieu. C'est ce qui le rend rationnel sur la durée, à condition d'accepter le coût d'entrée.
La courbe d'apprentissage et la gouvernance variable
Le deuxième coût est plus pénible à reconnaître pour quelqu'un qui défend l'open source : certains outils libres ont une courbe d'apprentissage rude. Pas tous. QGIS est aujourd'hui plus accessible que beaucoup de SIG propriétaires de son niveau. Odoo Community a une interface comparable à n'importe quel ERP du marché. Mais d'autres outils restent ingrats à prendre en main, surtout pour des utilisateurs métier sans bagage technique. Quand c'est le cas, il faut le dire.
Le troisième coût est plus structurel : la gouvernance des projets open source est extrêmement variable.
Fondation solide
Dizaines d'employés à plein temps, sponsors industriels, releases régulières, support pro disponible. Ces projets ne disparaîtront pas du jour au lendemain.
Mainteneur unique
Un développeur peut décrocher du jour au lendemain et le projet s'éteint avec lui. Ce risque ne se lit pas dans le README — il se lit dans l'activité du dépôt.
Fork communautaire
Un fork actif (OpenSearch, OpenTofu, Valkey) prouve que la communauté peut reprendre la main. C'est une assurance contre la dérive de l'éditeur original.
Cette différence ne saute pas aux yeux quand on regarde un dépôt de code, et c'est précisément ce qu'il faut apprendre à lire avant de s'engager sur un outil pour cinq ans.
Le risque que la licence change sous vos pieds
Il y a un dernier coût, plus inattendu, qui mérite d'être nommé honnêtement : un éditeur qui a publié son outil sous licence libre peut, du jour au lendemain, décider de durcir cette licence. Ce n'est pas une hypothèse théorique, c'est arrivé plusieurs fois ces dernières années sur des outils massivement utilisés en entreprise.
Trois cas marquants. Elasticsearch est passé de la licence Apache 2.0 à la SSPL en 2021, ce qui a donné naissance au fork OpenSearch porté par AWS puis transféré à la Linux Foundation. HashiCorp a relicencié Terraform de la MPL vers la BSL en 2023, déclenchant le fork OpenTofu.
Redis a basculé du BSD vers un modèle dual SSPL/RSALv2 en mars 2024, et la communauté a forké en quelques jours pour créer Valkey, lui aussi sous l'égide de la Linux Foundation. Dans chaque cas, des entreprises qui s'étaient appuyées en confiance sur l'outil libre se sont retrouvées contraintes de migrer ou de renégocier commercialement.
Cinq ans de relicences sur des outils massivement utilisés en entreprise
La parade existe et fonctionne — le fork communautaire — mais elle a un coût : il faut migrer, requalifier, parfois changer d'outil dans la chaîne.
Toutes les licences open source ne se valent pas, et certaines familles offrent des garanties plus fortes que d'autres contre ce type de retournement. Le détail des grandes familles de licences — permissives, copyleft, hybrides, faussement libres — sera traité dans le livre blanc qui accompagne le troisième article de cette série, avec une annexe dédiée pour distinguer les vraies licences libres des "source-available" qui se font passer pour OSS sans l'être.
Ce que l'open source offre en échange
Les coûts sont réels. Ce qu'on obtient en échange l'est tout autant — et c'est là que se trouve la justification de fond du choix.
L'interconnexion est dans la nature de l'open source
Un outil libre publie ses formats, ses APIs, son code. Sa licence l'oblige à le faire. Il ne peut pas enfermer ses utilisateurs, parce que les sources sont ouvertes et que n'importe qui peut reprendre le projet en cas de dérive. Cette contrainte structurelle force les projets open source à gagner sur la qualité technique, pas sur le verrou commercial.
La conséquence pratique est massive : les outils open source s'interconnectent entre eux par défaut. Vous pouvez brancher PostgreSQL sur n'importe quel langage ou framework qui parle SQL. Vous pouvez exporter QGIS vers à peu près tous les formats SIG du marché.
Vous pouvez faire dialoguer Odoo Community avec votre site, votre base, vos outils tiers. Sur la stack que j'utilise au quotidien, chaque brique parle à toutes les autres parce qu'aucune ne cherche à enfermer.
Ce constat n'est pas anecdotique. Le rapport State of Global Open Source 2025 de la Linux Foundation, publié en novembre dernier, observe que les organisations s'appuient désormais sur l'open source comme épine dorsale de leurs systèmes critiques. La raison principale est exactement celle-ci : l'interopérabilité native que l'écosystème libre rend possible.
Le propriétaire bride par construction — pas par malveillance
Il faut être juste avec les éditeurs propriétaires : ils ne brident pas par méchanceté ni même par calcul cynique. Ils brident parce que leur modèle économique en dépend, et parce que la spécialisation extrême de leur produit nécessite des choix techniques qui, mécaniquement, ferment des portes.
Si Adobe rendait Photoshop totalement interopérable avec GIMP, Adobe perdrait une partie de la rente qui finance ses développements et ses équipes. Si Autodesk ouvrait le format DWG complètement, AutoCAD perdrait son avantage de marché. Ces choix ne sont pas hostiles, ils sont structurellement liés au modèle de financement.
Demander à un éditeur propriétaire d'être aussi ouvert qu'un outil libre, c'est lui demander de saborder son propre modèle. Ça n'arrivera pas, et il faut faire avec.
Le décideur a tort de s'en offusquer. Il a raison d'en tenir compte au moment de choisir.
Open source et souveraineté française ou européenne sont deux questions liées mais distinctes. Quand on peut empiler les deux — un outil libre développé en Europe ou hébergé en France — c'est un bonus net. Quand on doit choisir entre les deux, l'arbitrage horizon temporel reste mon critère principal. Je traiterai cette question géographique en détail dans un prochain article, parce qu'elle mérite mieux qu'un détour.
La pérennité dans la durée : un format ouvert ne meurt pas
Il y a un argument qu'on entend rarement au moment du choix d'un outil et qui devrait peser plus lourd : un format ouvert ne meurt pas. Côté open source, la rétrocompatibilité est l'exception lorsqu'elle pose problème, pas la règle — et quand un format évolue, les outils de migration existent, sont gratuits, et fonctionnent.
Un document texte LibreOffice écrit en 2010 reste exploitable aujourd'hui sans rien faire. Quand PostgreSQL fait évoluer son format binaire entre deux versions majeures, l'outil de migration pg_upgrade est livré avec, gratuit, et reprend la base sans réécriture applicative. Quand QGIS modifie sa structure de projet entre versions proches, l'application gère elle-même la conversion à l'ouverture.
Sur des écarts plus importants, une mise à niveau intermédiaire peut être nécessaire — mais le format reste lisible et documenté.
Le point fondamental n'est pas que tous les formats libres restent identiques pendant vingt ans. C'est que vous ne dépendez pas d'un éditeur qui décide de retirer la compatibilité descendante pour vous pousser à payer une mise à niveau. L'écosystème open source ne fonctionne pas selon cette logique de rétention forcée — et le code reste là, accessible, pour celui qui voudrait écrire un convertisseur même très tard.
| Critère | Open source | Propriétaire |
|---|---|---|
| Rétrocompatibilité | ✅ Engagement explicite des fondations | ⚠️ Variable selon l'éditeur |
| Outil de migration | ✅ Fourni et gratuit (pg_upgrade, QGIS…) | ⚠️ Payant ou absent |
| Format documenté | ✅ Spécification publique (ODF, GeoPackage…) | ❌ Souvent propriétaire (DWG, .docx ancien…) |
| Risque éditeur | ✅ Fork possible si dérive | ❌ Service fermé = données perdues |
| Continuité 10 ans | ✅ Code accessible même sans mainteneur | ⚠️ Dépend de la survie commerciale de l'éditeur |
Cette différence n'est pas accessoire pour une entreprise qui produit du contenu, des données ou de la connaissance qu'elle veut conserver. Sur cinq ou dix ans, la pérennité du format devient un actif silencieux. On ne s'en aperçoit que le jour où on en a besoin — et ce jour-là, soit elle est là, soit elle n'est pas là.
L'arbitrage honnête : sur quel horizon vivez-vous avec l'outil ?
Avant de poser le critère, une remarque qui change la nature de la question. Vous utilisez déjà massivement de l'open source, sans toujours le savoir. La Linux Foundation rappelle que le logiciel libre constitue une part majeure de tout logiciel moderne — il est dans les bases de données, les serveurs web, les frameworks, les outils de construction, les systèmes d'exploitation mobiles.
Votre site WordPress fonctionne sur du PHP open source, sur un serveur Apache ou Nginx open source, sur un système Linux.
Votre application métier propriétaire est presque toujours bâtie sur des fondations libres que l'éditeur ne mentionne pas dans ses commerciaux.
Donc la vraie question n'est pas « faut-il choisir l'open source ». Vous l'avez déjà choisi, partout, en infrastructure.
La question est « où je le pousse en surface, là où mon équipe le voit et le manipule, et où je le laisse en infrastructure, invisible mais présent ». Et c'est là que le critère de décision suivant s'applique vraiment — étant entendu que l'outil seul, qu'il soit libre ou propriétaire, ne suffit jamais : la plupart des projets ERP, par exemple, échouent pour des raisons organisationnelles avant d'échouer pour des raisons techniques, et c'est vrai pour beaucoup d'autres outils structurants.
6 mois avec l'outil → le propriétaire peut suffire
Si vous savez que l'outil servira sur un projet ponctuel, une mission cadrée, une période courte qui ne se renouvellera pas, alors la rapidité de mise en route propriétaire l'emporte sur la liberté à long terme que vous n'aurez de toute façon pas le temps d'exploiter.
Un SaaS spécialisé pour répondre à un appel d'offres de quatre mois. Un outil de design propriétaire pour une refonte de site. Un service en ligne pour un événement.
Dans ces cas, payer une licence courte ou un abonnement mensuel et démarrer en deux jours est plus rationnel que d'investir une semaine de configuration sur un outil libre dont on n'exploitera jamais la liberté d'évolution. La logique économique est honnête, le décideur n'a pas à culpabiliser.
5 ans avec l'outil → l'open source gagne
À l'inverse, dès que l'outil structure votre activité — votre ERP cœur, votre SIG métier, votre plateforme produit, votre site qui héberge votre contenu et votre référencement — vous allez vivre cinq, dix, quinze ans avec lui. Sur cet horizon, le calcul s'inverse complètement.
Le coût initial de configuration de l'outil libre est amorti dès la deuxième année. La liberté d'évolution devient le critère qui compte vraiment : c'est elle qui détermine si vous pourrez encore faire bouger votre outil quand votre métier changera. Et la plupart des métiers finissent par changer.
Le bridage propriétaire qui semblait acceptable au démarrage devient le mur sur lequel vous butez à l'année quatre, quand vous voulez pivoter, intégrer un nouveau canal, brancher un partenaire, ou simplement changer de prestataire pour une raison qui vous regarde.
Les exceptions que j'assume
Cohérence oblige : MP-i n'est pas 100 % open source, et je ne le revendiquerai pas. Trois exceptions que j'assume publiquement.
Paiement en ligne
Aucun équivalent open source n'atteint le niveau de Stripe sur la sécurité, la conformité PCI-DSS et l'intégration bancaire. Je l'utilise en pleine conscience et le déclare à mes clients.
Infrastructure
Fournisseur propriétaire au sens commercial, mais français — donc européen. Quand le choix se pose entre un OSS américain hégémonique et un propriétaire européen, j'accepte le compromis.
IA managée
Aucun modèle open source n'atteint encore le niveau requis pour mon usage métier quotidien. Je surveille Gemma 4 (Apache 2.0) et Mistral. Si une alternative libre rattrape le niveau, je rebascule.
Cet arbitrage en jeu dans deux autres articles à venir
L'IA va-t-elle tuer l'open source ? Trois mécanismes à comprendre avant de paniquer — publication le 13 mai.
Trois forces tirent aujourd'hui sur le modèle open source : la captation des contributeurs par les grandes IA, la dilution de la valeur du code humain, et la dépendance croissante des projets libres aux infrastructures de calcul propriétaires. Faut-il paniquer ? Pas encore — mais il faut comprendre.
Choisir des outils open source pour son entreprise : grille de décision en 12 questions — publication le 20 mai.
L'arbitrage horizon temporel est le critère principal. Il y en a onze autres : gouvernance, communauté, dépendance à un mainteneur, souveraineté géographique, modèle de support, coût total réel sur cinq ans. Cet article livrera la grille complète, avec un livre blanc téléchargeable qui inclut une annexe dédiée au panorama des licences open source — pour reconnaître les garanties solides, les zones grises et les pièges récents.
Ce qu'il faut retenir
L'open source n'est ni gratuit ni magique. Il demande plus de configuration au démarrage, parce qu'il vise un public large. Il offre en échange une liberté d'interconnexion et d'évolution que les outils propriétaires brident par construction.
Le bon choix ne sort pas d'une idéologie — il sort d'une question pratique : combien de temps vais-je vivre avec cet outil ? Court terme, le propriétaire peut suffire. Long terme, l'open source en entreprise gagne presque toujours.
Vous n'avez pas à tout changer. Vous avez trois questions à poser, sur chacun des outils structurants de votre système d'information. Quel est mon horizon d'usage prévisible sur cet outil ? Si je dois changer de prestataire dans trois ans, est-ce que je peux partir avec mes données et continuer à les exploiter ? Quelle part de mon SI dépend aujourd'hui d'un éditeur unique — et est-ce que je suis à l'aise avec ce niveau de dépendance ? Les réponses vous diront, mieux qu'un consultant, où vous tenir et où bouger.