Le barbu AS400 : qui dit encore ça en 2026 ?
L'image est précise dans les têtes. L'open source, c'est le geek dans sa cave, l'écran noir avec une police verte qui défile, des commandes incompréhensibles tapées à minuit, et un système qui plante un week-end sur deux sans que personne ne sache pourquoi. C'est la culture AS400 fantasmée — un monde de spécialistes pour spécialistes, hostile à l'utilisateur, ingérable sans compétences très pointues.
Cette image avait une part de réalité en 1998. Linux s'installait en ligne de commande, les distributions étaient instables, la documentation était en anglais pour des utilisateurs déjà initiés, et effectivement — si vous vouliez un pilote pour votre carte réseau, vous passiez votre week-end dessus. J'étais là. Je m'en souviens.
Mais en 2026 — vingt-cinq ans plus tard — ce monde-là n'existe plus. Et pourtant le préjugé, lui, a survécu. Il circule dans les réunions de direction, dans les comités IT, dans les échanges entre DSI et DG. "On ne peut pas y aller sur l'open source, on n'a pas les compétences en interne." "Si ça plante, qui on appelle ?" "On ne peut pas se permettre de dépendre d'une communauté de bénévoles."
Ces objections méritent d'être prises au sérieux. Parce qu'elles ne sont pas stupides — elles étaient légitimes à une certaine époque. Ce qui est faux, c'est de les appliquer à l'état réel de l'open source aujourd'hui.
Ce que tourne le monde en 2026, en dessous du capot.
Commençons par un fait : la quasi-totalité de l'infrastructure Internet mondiale tourne sur des logiciels open source. Les serveurs qui font tourner votre banque, votre hôpital, votre plateforme d'e-commerce préférée, le cloud de votre éditeur de logiciel propriétaire favori — tout ça tourne sur Linux, Nginx, PostgreSQL, et des dizaines d'autres projets libres. Ce n'est pas un choix idéologique. C'est parce que ces outils sont, après vingt-cinq ans de maturation, parmi les plus solides, les plus documentés, et les mieux maintenus au monde.
Sur les terrains que je connais directement : Dolibarr gère la comptabilité, les devis, les factures, les commandes et les contrats de milliers de PME françaises. ChirpStack est le serveur LoRaWAN que nous utilisons pour SISKIA — c'est ce qui reçoit et route les données de capteurs de détection d'incendie déployés en forêt. Nextcloud remplace Google Drive ou SharePoint pour des centaines de collectivités et d'associations qui veulent garder la maîtrise de leurs fichiers. Mattermost remplace Slack ou Teams pour la communication interne, sans dépendre d'un éditeur tiers.
Panorama rapide — ce qui tourne en open source en 2026
OS : Linux (serveurs, Android, embarqué) — Bases de données : PostgreSQL, MariaDB, Redis, SQLite — Web : Nginx, Apache, Traefik — Frontend/Backend : Next.js, Node.js, TypeScript, Python — ERP/CRM : Dolibarr, ERPNext, Odoo (freemium) — Collab : Nextcloud, Mattermost — IoT : ChirpStack, ThingsBoard — IA : Mistral, Llama, Whisper (via Ollama) — Conteneurisation : Docker. Ce n'est pas une liste exhaustive. C'est juste ce que j'utilise en production, sur des missions réelles, avec des structures qui ont des budgets serrés et des exigences opérationnelles concrètes.
Les interfaces ont évolué. Nextcloud ressemble à un Google Drive moderne. Mattermost ressemble à Slack — parce qu'il s'en est ouvertement inspiré, et il est souvent meilleur sur la personnalisation et la confidentialité. ThingsBoard produit des dashboards IoT que je serais incapable de distinguer d'une solution propriétaire à 50 000 euros l'an. Et quand l'interface native d'un outil open source est vraiment datée — c'est le cas de Dolibarr — on pose une application métier par-dessus, et l'utilisateur final ne voit jamais l'ERP. Il voit un outil conçu pour lui.
Pourquoi le préjugé tient quand même.
Comprendre l'origine du préjugé, c'est comprendre pourquoi il est si résistant — et comment y répondre sérieusement plutôt que de le balayer d'un revers de main.
La première raison, c'est l'héritage Microsoft des années 1990. Microsoft a investi massivement dans l'argument "qui vous soutient si ça plante ?" à une époque où c'était une vraie question. Ils ont construit un réseau de partenaires certifiés, des contrats de support avec SLA, des numéros de téléphone auxquels répondait un humain. L'open source de l'époque n'avait rien d'équivalent. Cet argumentaire s'est gravé dans les habitudes de décision des DSI et des directions — et vingt-cinq ans plus tard, il est toujours cité comme si rien n'avait changé.
La deuxième raison, c'est le confort du vendor lock-in. Je dis "confort" sans ironie — il y a un vrai confort dans le fait que quelqu'un d'autre est responsable. Quand SAP plante, vous appelez SAP. Quand Salesforce a une panne, c'est leur problème. Cette externalisation de la responsabilité technique a une valeur réelle pour des structures qui n'ont pas de compétences internes. Ce que le lock-in ne dit pas, c'est combien il coûte quand l'éditeur décide d'augmenter ses tarifs de 30 % un beau matin — ou quand il acquiert un concurrent et décide de faire évoluer sa roadmap dans une direction qui ne vous convient plus.
La troisième raison, c'est une vraie expérience traumatique chez certains. Quelqu'un a essayé d'installer un outil open source il y a dix ans, s'est retrouvé coincé sur une dépendance Python, a passé deux jours à chercher pourquoi ça ne compilait pas, et a abandonné. Cette expérience est réelle. Elle n'est plus représentative de 2026 — mais elle laisse des traces.
Quand l'open source est la bonne réponse.
Je ne défends pas l'open source par idéologie. Je le choisis quand c'est objectivement la meilleure option — et dans un certain nombre de cas, ça l'est clairement.
La souveraineté sur les données. C'est l'argument le plus solide en 2026. Quand vous hébergez votre ERP chez vous, sur un serveur que vous contrôlez, vos données ne transitent pas chez un tiers. Elles ne sont pas monétisées. Elles ne partent pas dans un datacenter américain soumis au Cloud Act. Pour une association comme SISKIA qui collecte des données environnementales de terrain, pour une PME qui gère des contrats clients, pour un cabinet qui traite des données médicales — la maîtrise de l'hébergement n'est pas un luxe technique, c'est une obligation pratique.
L'indépendance tarifaire. Personne ne vous appelle un lundi matin pour vous annoncer que votre abonnement Dolibarr augmente de 40 % parce que l'éditeur a des actionnaires à satisfaire. Avec un outil open source, le seul coût qui évolue, c'est l'hébergement et l'accompagnement humain — deux choses sur lesquelles vous avez la main.
La scalabilité économique. Pour une structure qui part de zéro, ou qui a des budgets contraints, le modèle open source permet de démarrer à coût marginal faible et de faire monter la puissance sans revoir le modèle de licences. J'ai conçu ComiPi ERP, le SaaS métier que je développe sur mesure au-dessus de Dolibarr, pour des clients qui auraient payé 300 à 500 euros par mois pour une plateforme équivalente en SaaS propriétaire. L'économie sur trois ans est substantielle — et les fonctionnalités sont au moins équivalentes, taillées exactement pour le métier du client.
La durabilité du choix. PostgreSQL a 30 ans. Linux a 33 ans. Ces projets ne vont pas disparaître parce qu'un fond d'investissement a décidé de pivoter. Ils ne vont pas être rachetés et intégrés dans un autre produit qui ne vous convient pas. La communauté qui les maintient a des intérêts alignés avec ceux des utilisateurs — pas avec ceux d'actionnaires.
Ce que "open source" ne signifie pas
Open source ≠ gratuit. Le logiciel est libre. Le travail d'intégration, de configuration, de formation et de support, lui, se paye — et c'est normal. Ce que vous ne payez pas, c'est la licence. Ce que vous payez, c'est la compétence humaine pour en faire quelque chose d'utile et de stable. Ce modèle est souvent moins cher sur la durée qu'un abonnement SaaS — mais il faut être honnête là-dessus dès le départ.
Quand le propriétaire est encore meilleur — soyons honnêtes.
Je serai direct : il y a des cas où je recommande du propriétaire. Ce n'est pas une contradiction avec ce que je viens d'écrire. C'est simplement de l'honnêteté.
La suite Adobe reste, en 2026, sans équivalent open source pour certains usages créatifs professionnels. GIMP n'est pas Photoshop. Inkscape n'est pas Illustrator — et pour quelqu'un dont le métier est le graphisme de haut niveau, ces différences comptent. Je ne vais pas recommander Inkscape à une agence de création qui vit de son outil. Ce serait idéologique et contreproductif.
Certaines verticales métier très spécialisées — logistique, BTP, juridique, secteur médical — ont des éditeurs propriétaires qui ont investi des années dans des fonctionnalités sectorielles que l'open source généraliste ne couvre pas. Pour ces cas, l'intégration d'un outil propriétaire avec des briques open source autour peut être la meilleure architecture : on garde la maîtrise sur les couches génériques (hébergement, automatisation, collab) et on accepte le lock-in là où l'expertise sectorielle le justifie.
Et certains SaaS très spécialisés — outils de veille, plateformes de signature électronique, outils de réponse aux appels d'offres — sont objectivement mieux que ce qu'on construirait en open source, pour un prix raisonnable au regard du service rendu. Chez EVEIA par exemple, on a fait ce choix sur la partie veille AO : l'outil propriétaire fait le travail mieux qu'un outil qu'on aurait assemblé nous-mêmes, et le coût mensuel est justifié par le temps gagné.
Ma règle : open source quand c'est pertinent, propriétaire quand c'est objectivement mieux. Pas de dogme. Pas de posture. Du pragmatisme au cas par cas, avec les arguments sur la table.
Ce que ça donne concrètement dans une mission.
Quand j'arrive chez un client, je ne pose pas d'emblée "on va faire tout ça en open source". Je fais un audit des besoins réels. Ce que les équipes font au quotidien, ce qui frotte, ce qui prend du temps pour rien, ce qui est mal maîtrisé. Et ensuite, je propose une architecture qui répond à ces besoins — parfois en open source, parfois en mixte, parfois avec un outil propriétaire qui fait clairement mieux.
Ce que j'explique systématiquement à ce stade : les critères de choix. Pourquoi cet outil et pas un autre. Ce que ça coûte vraiment — licences, hébergement, intégration, formation, support. Ce que ça coûte de changer d'outil dans cinq ans si les besoins évoluent. La question du lock-in — propriétaire ou open source — est posée sur la table, pas glissée sous le tapis.
Ensuite vient l'intégration. Dans ComiPi ERP, je code les flux entre les outils : quand un devis est accepté dans l'application métier, la commande s'ouvre dans Dolibarr via son API, une notification part dans Mattermost, le client reçoit une confirmation par mail. Tout ça en Node/TypeScript, intégré au backend ComiPi ERP, versionné, testé. Sans que quelqu'un ait à faire trois actions dans trois outils différents. Ce travail d'intégration, c'est là que réside la vraie valeur — pas dans le choix de tel ou tel logiciel, mais dans la façon dont les outils s'imbriquent dans le quotidien des équipes.
Et enfin la transmission. L'objectif d'une mission ComiPi n'est pas que je reste indispensable. C'est que les équipes comprennent ce qu'elles ont mis en place, sachent le faire évoluer, et puissent appeler un prestataire compétent — moi ou quelqu'un d'autre — si elles ont besoin d'aide. L'open source facilite ça : la documentation est publique, les compétences se trouvent sur le marché, il n'y a pas de pépite propriétaire qui ne peut être maintenue que par un seul acteur.
Ce que cette conviction m'a appris sur la durée.
J'ai vu Linux passer du statut de curiosité de geek à celui d'infrastructure invisible — parce que présente partout. Ce basculement n'a pas duré dix ans : il a duré vingt-cinq ans. Et il s'est fait sans fanfare, sans révolution marketing, juste par la qualité accumulée d'un logiciel maintenu par des milliers de contributeurs qui avaient intérêt à ce qu'il soit bon.
C'est ce que les préjugés ne voient pas : la maturité acquise dans le temps long. PostgreSQL n'est pas devenu la base de données de référence parce qu'une startup bien financée a fait une levée de fonds. C'est devenu la référence parce que trente ans de contributions ont produit quelque chose d'irréprochable. Cette durée-là, dans l'industrie logicielle, ne s'achète pas.
Ce que je retiens après vingt-cinq ans à regarder ces choix de près : la vraie question n'est pas "open source ou propriétaire ?" La vraie question est "qui maîtrise quoi, et à quel coût sur la durée ?" Les structures qui se posent cette question honnêtement arrivent souvent à une architecture mixte — quelques briques propriétaires là où elles sont irremplaçables, open source partout ailleurs. Pas par idéologie. Parce que c'est ce qui tient.
Et les barbus AS400 ? Ils existent encore. Mais ils maintiennent le kernel Linux dans des datacenters qui font tourner la moitié d'Internet. Ce n'est plus vraiment le profil qu'on doit avoir peur d'appeler.
Pour aller plus loin
- 1999 → 2026 : ce que j'ai mis 25 ans à mettre en musiqueLe manifeste qui ancre la posture ComiPi — pourquoi l'info qui circule est la conviction fondatrice, et comment l'IA a rendu possible ce qui était en tête depuis 1999.
- Pourquoi Dolibarr moche + app UX, c'est l'architecture qui tient en 2026Le détail de l'architecture ComiPi : Dolibarr comme socle légal, application métier par-dessus pour l'UX, et pourquoi cette séparation est plus solide que les alternatives.
- N8N en 5 minutes sur ton PC : automatiser ton taf en localComment on orchestre les flux entre outils — Dolibarr, Mattermost, mails, agents IA — sans abonnement à 400 euros par mois, et sans compétences DevOps internes.
Vous avez ce débat dans votre structure ?
On peut regarder ça ensemble.
Si vous êtes en train de choisir une architecture — ou de questionner l'existante — je suis disponible pour un premier échange sans engagement. On pose les critères sur la table.
La méthode ComiPi en détail
Blog ComiPi
Cas clients, arbitrages techniques, choix d'architecture. Pas de newsletter — des articles quand il y a quelque chose de concret à dire.