Quand le logiciel privateur nous abandonne

Pourquoi cet article#

J’ai passé plus de vingt ans à développer et à architecturer des logiciels. Pendant ces années, j’ai vu se répéter le même scénario : une entreprise technologique décide, seule et unilatéralement, d’abandonner une technologie, de casser une compatibilité, de changer un prix ou une licence — et des utilisateurs, des indépendants, des associations, des entreprises entières se retrouvent « le bec dans l’eau ». Pas par accident, mais parce que le modèle même du logiciel privateur le permet.

Un mot sur le vocabulaire. L’anglais proprietary se traduit habituellement par « propriétaire » — un terme neutre, qui décrit qui détient le code. Richard Stallman et la communauté du logiciel libre francophone lui préfèrent « privateur » : il ne désigne pas un autre type de logiciel, mais le même sous un autre angle. Là où « propriétaire » parle de possession, « privateur » nomme l’effet sur l’utilisateur — ce type de logiciel prive l’utilisateur de ses libertés : celle d’étudier le programme, de le modifier, de le corriger, de le faire vivre quand son éditeur a décidé de le laisser mourir. Ce n’est donc pas une coquetterie, et c’est le mot que j’emploie dans cet article. Avec un logiciel privateur, comme l’explique Stallman, ce n’est pas l’utilisateur qui contrôle le programme : c’est le programme qui contrôle l’utilisateur, et c’est l’éditeur qui contrôle le programme. (Voir la définition du logiciel libre et « Le logiciel libre est encore plus essentiel maintenant ».)

Cet article repose sur des situations réelles : pour la plupart, des murs sur lesquels je me suis personnellement heurté ; pour le reste, des cas que j’ai vus frapper mes proches, ou qui m’ont été rapportés par d’autres professionnels de mon secteur — et je le signale au fil du texte. Il montre ensuite ce que le logiciel libre aurait changé, et ouvre une série, en cours d’écriture, sur le logiciel libre et les licences. Je ne raconte pas une théorie. J’ai vérifié les faits et les dates auprès de sources publiques, listées en fin d’article ; quand un souvenir n’a pas pu être confirmé précisément, je le signale.

Expérience 1 — L’école de musique et Microsoft Access#

À la fin des années 1990, le directeur d’une école de musique développe lui-même, sur son temps libre, un logiciel de gestion de son établissement. Il s’appuie sur Microsoft Access 2.0 (avril 1994), un outil pensé pour des non-développeurs : des gens qui n’ont pas de culture du génie logiciel — ni tests unitaires, ni tests de bout en bout — et pour qui, de toute façon, les frameworks permettant ces pratiques n’existaient pas dans cet environnement à l’époque. Des nuits et des week-ends de travail pour fiabiliser et simplifier l’administration de l’école, et faire gagner du temps à tout le monde.

Puis arrive la version suivante, Access 95 (août 1995). Et là, c’est la rupture. Entre Access 2.0 et Access 95, la compatibilité est cassée en profondeur :

  • le langage interne change complètement : Access 2.0 utilisait Access Basic, remplacé par VBA (Visual Basic for Applications) dès Access 95 ;
  • on passe du 16 bits au 32 bits : tous les appels d’API système doivent être réécrits ;
  • de nouvelles règles de nommage interdisent ce qui était autorisé avant (un module et une procédure ne peuvent plus porter le même nom) ;
  • le moteur de base de données lui-même change (Jet 2.0 → Jet 3.0).

Petite précision par rapport à mon souvenir : je situais la rupture à Access 97 (janvier 1997), mais c’est en réalité Access 95, la version immédiatement postérieure à la 2.0, qui a brisé la compatibilité. Les versions d’après n’ont fait qu’en rajouter une couche : Access 97 introduit par exemple de nouveaux mots-clés réservés (AddressOf, Enum, Event, Implements…) qui cassent à leur tour le code qui les utilisait comme noms. Le résultat est le même : pour passer de l’application Access 2.0 aux versions modernes, il fallait convertir le fichier puis réécrire et retester une bonne partie du code, sans traducteur automatique fiable ni guide de migration digne de ce nom.

Pour moi, Microsoft a tout simplement abandonné ces clients-là. Des gens qui avaient acheté Access 2.0 et investi leur temps personnel pour améliorer leur organisation. Et même si le code avait été parfaitement « traduit », il aurait fallu tout retester — un coût exorbitant pour une petite structure sans équipe de développement ni filet de sécurité automatisé. Au début des années 2000, j’ai moi-même tenté de récupérer ce code et de le migrer vers une version récente d’Access. Je me suis heurté au même mur.

Sur les difficultés réelles de conversion depuis Access 2.0, voir la fiche d’Allen Browne, « Issues in converting from Access 2 », et la documentation Microsoft sur l’import des bases Access 2.0 et 95.

Expérience 2 — Homelidays et les millions de lignes de Classic ASP#

En 2009, j’entre comme architecte chez Homelidays. Le site repose sur Classic ASP : plusieurs millions de lignes de code. Or Classic ASP est déjà une technologie de fin de vie : sa dernière version stable date de 2000, et Microsoft a publié son successeur, ASP.NET, en 2002. Le code continue de s’exécuter, mais la technologie est morte : plus d’évolution, plus d’avenir.

Le problème, c’est qu’avec une telle masse de code, migrer vers VB.NET ou C# représente un investissement colossal. Impossible de tout réécrire d’un coup. Avec le directeur technique de l’époque, nous lançons une migration progressive vers C# : tout nouveau développement se fait en C#, et le Classic ASP est gelé en maintenance évolutive seulement. Vers 2014 (de mémoire), il restait encore environ deux millions de lignes de Classic ASP en production. C’est de cette période qu’est né un composant que j’ai publié en open source — à l’époque sur CodePlex, aujourd’hui sur mon GitHub : le Homelidays Session Service, pour faire cohabiter les sessions entre l’ancien monde ASP et le nouveau monde .NET.

Et c’est précisément à ce moment-là que Microsoft nous explique que ASP.NET Web Forms — la technologie vers laquelle une partie du chemin de migration menait — ne sera plus vraiment développée, au profit d’ASP.NET MVC (sorti en 2009). Comme pour Classic ASP : le code tourne encore, mais l’investissement s’arrête. Plus tard, ASP.NET Core (2016) abandonnera purement et simplement Web Forms. Encore une fois, une décision unilatérale de l’éditeur qui menaçait de nous laisser le bec dans l’eau.

Cette fois pourtant, nous y avons échappé — mais pas grâce à un choix qui nous appartenait : Homelidays avait été racheté par HomeAway, qui a entrepris de migrer le site sur la stack technologique du groupe, basée sur Java. Autrement dit, c’est une décision d’entreprise — et non la pérennité de la technologie Microsoft — qui nous a sortis de l’impasse. Sans ce rachat et cette migration, nous serions bel et bien restés le bec dans l’eau. Tout le monde n’a pas la chance d’être adossé à un groupe capable de financer une telle bascule.

Expérience 3 — Visual Studio et les projets d’installation MSI supprimés#

Pendant des années, Visual Studio a proposé un type de projet dédié — les Setup and Deployment Projects (fichiers .vdproj) — qui permettait de générer simplement un installeur MSI (Windows Installer) pour ses applications : choix des fichiers à déployer, raccourcis, clés de registre, actions personnalisées… C’était une fonctionnalité intégrée à Visual Studio, donc déjà incluse dans la licence que l’on payait (dans mon cas, via l’abonnement MSDN de mon employeur), et largement utilisée.

Puis, avec Visual Studio 2012, Microsoft a tout simplement retiré ce type de projet. Visual Studio 2010 aura été la dernière version à l’inclure nativement. À la place, Microsoft renvoyait vers InstallShield Limited Edition, un produit tiers (Flexera) bridé : pas de support x64, pas d’installation de services Windows, pas d’actions personnalisées, pas de support VSTO… et conçu, comme son nom l’indique, pour pousser à l’achat de la version complète. Du jour au lendemain, un projet d’installation qui fonctionnait ne pouvait plus être maintenu dans la nouvelle version de l’outil sans le réécrire avec une solution tierce, payante ou limitée.

La réaction de la communauté a été massive. Sur UserVoice — la plateforme où Microsoft recueillait alors les retours sur Visual Studio — la demande de rétablir ce type de projet est devenue la deuxième suggestion la plus votée de tout le forum Visual Studio. Et pendant des années, Microsoft n’en a pas tenu compte : VS 2012 puis VS 2013 sont sortis sans support natif.

Honnêteté oblige, l’histoire ne s’arrête pas là : Microsoft a fini par céder. En avril 2014 (version finale en juin 2014), l’éditeur publie une extension Visual Studio Installer Projects qui réintègre la fonctionnalité, extension qui existe d’ailleurs encore aujourd’hui (jusqu’à Visual Studio 2022). La fonction est donc bien revenue — mais seulement quatre ans après VS 2010, un délai pendant lequel tous ceux qui en avaient besoin ont dû bricoler des solutions de contournement.

Je n’ai moi-même appris ce revirement qu’en documentant cet article : à l’époque, je travaillais chez HomeAway et nous migrions vers la stack Java du groupe (voir l’expérience précédente), si bien que j’avais quitté ce monde et que je n’ai jamais su que Microsoft avait fini par rétablir la fonction. Que la demande la mieux classée — la n°2 — d’une plateforme de feedback officielle mette quatre ans à être (partiellement) entendue en dit long sur le rapport de force : même très nombreux et très visibles, les utilisateurs n’ont aucune prise réelle sur les décisions de l’éditeur.

Sources : Visual Studio Blog, « Visual Studio Installer Projects Extension » · InfoQ, « Visual Studio 2013 Installer Project ».

Expérience 4 — Le dépôt-vente et la licence Windows#

Il y a quelques années, ma femme monte un dépôt-vente, La Petite Fouine (lien vers une capture d’archive de 2018). Je lui développe un logiciel de gestion sous forme d’application web, en ASP.NET MVC / Entity Framework 6 / .NET Framework 4.6. Pour l’héberger, je loue chez Dedibox un petit serveur à une dizaine d’euros par mois (de mémoire, 10 à 15 €).

Puis un jour, sans que rien ne change techniquement — même serveur, même version de Windows — la facture passe à environ 45 € par mois. La raison : Microsoft a modifié unilatéralement les conditions de licence de Windows Server, et l’hébergeur, qui répercute le coût de la licence, est contraint de facturer beaucoup plus cher.

Le serveur physique vaut toujours le même prix. C’est uniquement la licence du système privateur qui explose. Pour un dépôt-vente qui ne dégage même pas un SMIC, 30 € de plus par mois, ça compte énormément. Là encore, dépendre d’un logiciel non libre, c’est dépendre du bon vouloir du fournisseur — sans aucune prise sur sa décision.

Expérience 5 — Windows 7 puis Windows 10 : le gâchis imposé#

Le 14 janvier 2020, Microsoft met fin au support de Windows 7. À ce moment-là, l’OS est encore massivement utilisé : les estimations parlent d’environ 200 millions de PC qui tournaient encore sous Windows 7 fin 2019 (mon souvenir disait 250 millions ; le chiffre sourcé est plutôt de l’ordre de 200 millions, ce qui reste énorme).

La Free Software Foundation lance alors la campagne « Upcycle Windows 7 » : elle demande à Microsoft de libérer le code source de Windows 7 pour qu’une communauté puisse le maintenir, et éviter ainsi de jeter à la poubelle des millions d’ordinateurs encore parfaitement fonctionnels. La pétition, qui visait 7 777 signatures, dépasse largement son objectif (plus de 13 600 signataires à ce jour). Microsoft n’y donne aucune suite.

L’histoire se répète avec Windows 10, dont le support s’arrête le 14 octobre 2025 — alors qu’à cette date, le parc est encore gigantesque. Et cette fois, le problème écologique est pire : on estime à environ 400 millions le nombre de PC qui ne peuvent pas migrer vers Windows 11 faute de matériel compatible (l’exigence d’une puce TPM 2.0, notamment). Microsoft propose bien des mises à jour de sécurité étendues (ESU), mais payantes (de l’ordre de 30 $/an pour les particuliers).

Le résultat est double : un gâchis écologique considérable (des centaines de millions de machines poussées vers la benne ou vers l’obsolescence forcée) et un non-respect des utilisateurs, à qui l’on impose un calendrier qu’ils n’ont pas choisi. Avec un système libre, une communauté aurait pu prolonger la sécurité de ces machines aussi longtemps qu’elle le souhaite. Avec un système privateur, c’est interdit : personne d’autre que l’éditeur n’a le droit de toucher au code.

Je ne parle pas ici d’un drame abstrait : dans ma propre famille, plusieurs ordinateurs encore parfaitement utilisables ont été rendus obsolètes par ces fins de support.

Expérience 6 — Windows Phone : un nouveau téléphone à chaque génération#

Cet exemple-là, je ne l’ai pas vécu comme développeur, mais comme observateur — il m’a marqué parce qu’il déplace la mécanique du logiciel privateur de l’ordinateur vers un objet qu’on a en permanence dans la poche.

La lignée mobile de Microsoft a imposé deux ruptures matérielles successives en l’espace de deux ans, à chaque fois sans chemin de mise à niveau :

  • Windows Mobile 6.x (2007) → Windows Phone 7 (2010). Windows Phone 7 est une plateforme entièrement nouvelle (Silverlight, XNA, .NET) assortie d’exigences matérielles strictes. En mars 2010, Microsoft confirme que les appareils Windows Mobile 6.x ne seront pas mis à jour vers Windows Phone 7, et que les applications de l’ancien monde n’y fonctionnent pas.
  • Windows Phone 7 (2010) → Windows Phone 8 (2012). Rebelote : Windows Phone 8 bascule sur le noyau Windows NT et vise des appareils multicœurs. Les téléphones Windows Phone 7 ne peuvent pas être mis à niveau vers Windows Phone 8. Microsoft ne leur propose que Windows Phone 7.8 (décembre 2012), une mise à jour essentiellement cosmétique qui rétroporte le nouvel écran d’accueil — mais pas le système.

Autrement dit, un utilisateur qui voulait simplement rester à jour a dû, en deux ans, changer de téléphone deux fois — non parce que son appareil était cassé ou usé, mais parce que son matériel avait été déclaré incompatible. Et c’est le point qui me marque le plus : un téléphone rendu obsolète par le logiciel au bout de deux ou trois ans n’est pas un téléphone en fin de vie. L’électronique, elle, est loin d’être hors d’usage ; ce qui s’arrête, c’est la volonté de l’éditeur de la prendre en charge. Avec un système privateur, personne d’autre n’a le droit de prolonger la vie de l’appareil. C’est exactement la mécanique de l’expérience précédente (Windows 7 et 10), mais sur un objet du quotidien.

Soyons justes : ce travers n’était pas propre à Microsoft. Pendant longtemps, un support logiciel court a été la norme dans une grande partie du monde Android (souvent deux à trois ans d’évolutions majeures), tandis qu’Apple se distinguait par un suivi nettement plus long — de l’ordre de cinq à sept ans dans les faits, avec des correctifs de sécurité au-delà (l’iPhone 5S, sorti en 2013, recevait encore un correctif de sécurité en 2026). Par honnêteté, une nuance s’impose : Apple n’a jamais formellement « promis » un nombre d’années ; il s’agit d’un constat a posteriori, pas d’un engagement annoncé.

La bonne nouvelle, c’est que la situation s’est nettement améliorée — et il serait malhonnête de le passer sous silence :

  • depuis 2023, Google garantit sept ans de mises à jour (système et sécurité) sur ses Pixel, à partir du Pixel 8 ;
  • Samsung a suivi début 2024 en s’engageant sur sept ans pour le Galaxy S24 ;
  • et depuis le 20 juin 2025, l’Union européenne impose un plancher : le règlement écoconception (UE) 2023/1670 exige au moins cinq ans de mises à jour du système et de sécurité après l’arrêt de commercialisation d’un modèle, ainsi que la disponibilité des pièces détachées pendant au moins sept ans.

Reste une question ouverte, que je pose sans prétendre la trancher : sept ans, est-ce vraiment suffisant ? C’est un progrès considérable par rapport aux deux ou trois ans de l’époque Windows Phone. Mais quand le matériel peut durer bien plus longtemps, l’écart entre la durée de vie physique de l’appareil et la durée de vie logicielle qu’on lui accorde reste le cœur du problème. Et la différence décisive demeure la même que dans toutes les autres histoires : avec un système privateur, cette durée dépend du calendrier d’un seul fournisseur ; avec un système libre, une communauté peut prolonger le support aussi longtemps qu’elle le souhaite — c’est précisément ce que font des projets comme LineageOS ou /e/OS, qui redonnent des années de vie à des téléphones abandonnés par leur fabricant.

Sources : TechCrunch, « Microsoft: No, WinMo 6.5 devices will not be upgraded to Windows Phone 7 » · PCWorld, « Windows Phone 7 Users Can’t Upgrade to WP8 » · Engadget, « Samsung pledges seven years of updates for S24 series » · Commission européenne, « New EU rules for durable, energy-efficient and repairable smartphones » (règlement (UE) 2023/1670).

Expérience 7 — OneDrive et nos photos de famille#

Un soir, en 2024, je jette un œil sur l’ordinateur de ma femme et je vois quelque chose d’inquiétant : toutes nos photos stockées sur OneDrive sont en train de disparaître localement de sa machine. 400 Gio de photos de famille qui s’effacent du disque — pas de OneDrive, juste la copie locale. Une fois l’opération terminée, à la place du dossier de photos, il ne reste qu’un raccourci .url : quand on clique dessus, ça ouvre un navigateur web. Même chose pour le dossier qui contenait la base KeePass que je partage avec ma femme.

Nous avions chacun un abonnement Microsoft 365 Famille avec 1 Tio de stockage, et ni l’un ni l’autre n’avions atteint son quota. Un dossier que je partageais avec elle, et qui se synchronisait localement depuis des années, a cessé du jour au lendemain d’être disponible hors ligne — cassant notre organisation familiale et m’obligeant à chercher une solution de remplacement en urgence (la base de mots de passe partagée n’étant soudain plus accessible localement).

Le phénomène a été largement documenté à partir de juin 2024 : des dossiers partagés synchronisés localement se transformaient en raccourcis internet, renvoyant vers l’interface web au lieu d’ouvrir le contenu en local. Microsoft a fini par reconnaître le problème — mais en le qualifiant de bug (« OneDrive engineering is working on this issue »), pas de choix délibéré ; le problème a tout de même persisté de longs mois.

Et c’est précisément là que tout se joue. Que ce soit un bug ou une décision ne change rien pour l’utilisateur : avec un service privateur et fermé, on ne peut ni corriger soi-même, ni confier le correctif à quelqu’un d’autre. On subit, et on attend le bon vouloir de l’éditeur — pendant des mois, sur ses propres photos de famille et ses propres mots de passe.

Sources : Neowin, « Microsoft confirms OneDrive shared folders are indeed turning into internet shortcuts » · Windows Latest, « Microsoft confirms Windows 11 OneDrive internet shortcut bug ».

Expérience 8 — Balsamiq et le format de fichier prisonnier#

Chez Prothesis Dental Solutions, mon équipe — cinq personnes, moi compris — utilisait Balsamiq pour Google Drive pour ses maquettes (mockups). Notre organisation était simple et efficace : pour chaque projet ou fonctionnalité, un dossier sur Google Drive, et dans ce dossier un fichier de maquette Balsamiq.

Du jour au lendemain — quelques semaines en réalité — Balsamiq a déprécié sa version pour Google Drive, nous obligeant à basculer vers sa version Cloud, à la tarification différente. Notre organisation d’équipe était cassée, et il fallait nous réorganiser à un moment où nous avions par ailleurs beaucoup de sujets urgents à traiter. Pour être juste, Balsamiq a justifié cet arrêt (effectif le 17 décembre 2024) par des coûts de maintenance qu’il ne pouvait plus assumer et par sa volonté de se concentrer sur Balsamiq Cloud — une raison parfaitement légitime de son point de vue. Mais pour nous, l’effet était le même : une échéance subie, imposée de l’extérieur.

Après avoir étudié la nouvelle tarification, testé la version Cloud et découvert au passage un bug qui rendait l’import de nos fichiers difficile, nous avons fini par réussir la migration — mais en y perdant un temps et un argent précieux à ce moment-là. Et nous étions pris au piège : forcés de migrer à la date décidée par l’éditeur, sans pouvoir nous tourner vers un autre outil, car le format de fichier de Balsamiq n’est ni standard ni ouvert. Le format privateur n’enferme pas seulement le logiciel : il enferme vos données.

Source : Balsamiq, « Looking back at Balsamiq’s 2024 » (« We retired Balsamiq Wireframes for Google Drive and began winding down Desktop »). La page d’annonce dédiée (« What happened to Balsamiq for Google Drive? ») n’est aujourd’hui plus en ligne.

Expérience 9 — PC Soft : changer les règles en cours de partie#

Dernier cas — le seul que je n’ai pas vécu directement, mais qui m’a été rapporté par des développeurs de mon réseau dont le modèle économique se trouve menacé. L’éditeur français PC Soft (WinDev, WebDev, WinDev Mobile) a été racheté par le groupe canadien Volaris Group (printemps 2025). Dans la foulée, le modèle économique change radicalement.

Avant : on payait une licence pour les outils de développement, et le runtime était gratuit — on déployait son application autant qu’on voulait, sur autant de postes ou de serveurs qu’on voulait, sans surcoût. Après le rachat : fin de la licence perpétuelle, passage à un abonnement (SaaS), et surtout facturation au runtime / à l’usage.

Pour qui développe avec une petite équipe mais déploie massivement, le changement est brutal : une même application qui ne coûtait rien à déployer peut désormais représenter de quelques milliers à potentiellement plusieurs millions d’euros selon le volume de déploiement. Des modèles économiques jusque-là viables deviennent non viables du jour au lendemain — non pas parce que le logiciel a changé, mais parce que le propriétaire de l’outil a changé les règles en cours de partie. C’est l’illustration parfaite de la dépendance : on ne possède pas vraiment l’outil avec lequel on a construit son entreprise.

Sur ce changement et la réaction de la communauté, voir l’article de Next, « Les développeurs WinDev s’alarment d’une possible redevance par installation client ».

Expérience 10 — Azure DevOps : des projets prisonniers de leur collection#

Cet exemple-là, je le tire de mon quotidien d’architecte. Azure DevOps organise le travail en Team Project Collections (collections de projets d’équipe) : chaque collection regroupe les projets d’une équipe ou d’une entité, et le schéma de départ est simple — une équipe = une collection. Mais les organisations vivent : les équipes fusionnent, se scindent, se réorganisent ; les projets changent de main, les backlogs sont transférés. Et là, le mur : une fois un projet placé dans une collection, il est impossible de le déplacer vers une autre. Aucun outil intégré ne permet à la structure des projets Azure DevOps de suivre la réalité des équipes de développement.

Le besoin n’a rien d’exotique — c’est le quotidien de n’importe quelle organisation qui grandit. Il a d’ailleurs été formalisé publiquement : sur la plateforme de retours de Microsoft (Developer Community), la demande « make it possible to move a Team Project between Team Project Collections » a été ouverte le 24 octobre 2018. Au moment où j’écris (21 juillet 2026), elle totalise 1 158 votes et 209 commentaires — et son statut affiché reste « en cours d’examen » (Under Review).

Capture de la demande sur la Developer Community de Microsoft : « make it possible to move a Team Project between Team Project Collections », statut « Under Review », 1 158 votes et 209 commentaires, ouverte le 24 octobre 2018 par Feedback Bot, migrée depuis le forum UserVoice d’Azure DevOps (étiquette « uservoice votes 4385 »).

La demande sur la Developer Community de Microsoft, telle qu’affichée le 21 juillet 2026 : 1 158 votes, 209 commentaires, statut « Under Review », et l’étiquette « uservoice votes 4385 » héritée de l’ancien forum UserVoice.

Mais la demande est en réalité bien plus ancienne que cette date. Elle a été migrée depuis l’ancien forum UserVoice d’Azure DevOps, où elle avait déjà recueilli 4 385 votes avant même d’atterrir sur la Developer Community — un chiffre que Microsoft a conservé sous forme d’étiquette (uservoice votes 4385) sur la demande, visible dès 2019 sur une capture d’archive. Et le problème lui-même est plus vieux encore : la notion de Team Project Collection vient de Team Foundation Server (TFS), le produit sur lequel Azure DevOps est bâti. TFS existe depuis 2005 ; il a été renommé Visual Studio Team Services puis Azure DevOps (2018) côté cloud, et Azure DevOps Server (2019) côté sur site. Autrement dit, cela fait près de huit ans que la demande est formellement enregistrée — et le blocage existait déjà des années auparavant, sous TFS.

La réponse officielle de Microsoft ? Le déplacement est architecturalement difficile : dans la conception héritée de TFS, certains identifiants clés — les numéros de changeset TFVC, les identifiants de work items — sont séquentiels et rattachés à la collection, et référencés partout (code source, tâches, tableaux de bord, requêtes, builds, tests…). Les renuméroter en changeant de collection casserait tous ces liens. Microsoft en conclut qu’il n’y a « pas de plan pour livrer cette fonctionnalité » et renvoie vers des contournements partiels (scission de collection, outils de migration tiers) qui ne réalisent jamais un déplacement complet et fidèle.

Le raisonnement est peut-être techniquement fondé. Mais c’est justement le cœur du problème : la dette de conception d’un éditeur devient la prison de ses utilisateurs. Un choix d’architecture vieux de vingt ans — rattacher des identifiants à une collection — est aujourd’hui subi par toutes les équipes qui ne peuvent pas faire coïncider leurs projets avec la réalité de leur organisation, et qui n’ont, encore une fois, aucune prise pour le corriger elles-mêmes. Avec un système fermé, huit ans de votes ne pèsent rien face à une décision d’architecture qu’on n’a pas le droit de toucher.

Le point commun : qui contrôle réellement le logiciel ?#

Dix histoires, une même mécanique. À chaque fois, une décision — ou une défaillance — de l’éditeur détruit l’investissement de l’utilisateur, sans qu’il ait son mot à dire :

  • Access : compatibilité cassée, code à réécrire et à retester intégralement ;
  • Classic ASP / Web Forms : technologie abandonnée, sans alternative indolore ;
  • Visual Studio : type de projet d’installation supprimé du jour au lendemain, demande #2 sur UserVoice ignorée quatre ans ;
  • Windows Server : prix de licence qui explose, à matériel identique ;
  • Windows 7 / 10 : fin de support imposée, machines jetées, refus de libérer le code ;
  • Windows Phone : deux ruptures matérielles en deux ans, des téléphones encore fonctionnels rendus obsolètes par le seul logiciel ;
  • OneDrive : synchronisation locale rompue, organisation familiale cassée, aucun correctif possible de notre côté ;
  • Balsamiq : produit déprécié, migration forcée, données prisonnières d’un format privateur ;
  • PC Soft : modèle économique retourné, viabilité détruite ;
  • Azure DevOps : projets impossibles à déplacer, huit ans de votes ignorés au nom d’une dette de conception héritée de TFS.

C’est exactement ce que décrit Richard Stallman : avec le logiciel privateur, le développeur a un pouvoir sur les utilisateurs qu’aucune bonne intention ne suffit à rendre acceptable, parce que ce pouvoir est structurel. L’utilisateur n’a pas le code. Il ne peut pas le corriger, le prolonger, le confier à quelqu’un d’autre. Il ne peut que subir — ou tout recommencer.

Le logiciel libre : retrouver une marge de manœuvre#

Quand on utilise un projet libre (et donc open source), on n’est plus prisonnier. On dispose d’options qui n’existent tout simplement pas avec le privateur :

  1. Maintenir soi-même le projet, puisqu’on a le code source et le droit de le modifier ;
  2. Fédérer ou rejoindre une communauté qui le maintient ;
  3. Profiter du travail des autres : avec un peu de chance, d’autres financent et entretiennent le projet, et il ne reste qu’à contribuer — financièrement, par l’entraide entre utilisateurs, ou par le code.

Quelques illustrations, vérifiées :

  • PHP plutôt qu’Access ou Classic ASP. Avec le recul, à la fin des années 1990, partir sur PHP aurait été un meilleur pari de pérennité. Je ne prétends pas que les montées de version de PHP aient été indolores — elles ont parfois été douloureuses — mais elles étaient possibles, et personne ne pouvait du jour au lendemain vous interdire de continuer.

  • net2ftp, un client FTP en PHP que j’ai connu au tout début des années 2000. Sa dernière version stable (1.3) date de juillet 2019, sans changement de technologie de fond sur toute cette durée. Un outil libre peut traverser deux décennies parce que personne ne décrète sa mort. (Je n’ai pas pu confirmer publiquement la date exacte de sa toute première version ; je la situe « au début des années 2000 » de mémoire.)

  • Python 2 → Python 3, l’exemple le plus parlant. Python 3.0 sort en décembre 2008, en cassant volontairement la compatibilité. Mais comme l’écosystème est libre et piloté par la communauté, Python 2.7 a été maintenu en parallèle jusqu’au 1ᵉʳ janvier 2020 — plus de onze ans. (La date de fin de vie a même été repoussée de 2015 à 2020 pour laisser à tout le monde le temps de migrer.) Personne n’a été mis devant le fait accompli : chacun a pu migrer à son rythme. C’est exactement ce qu’aucune des dix histoires précédentes n’a permis.

La différence est là : avec le libre, une rupture reste gérable, parce que le pouvoir de décision n’est pas confisqué par un seul acteur.

Et moi, dans tout ça ? Un chemin, pas une posture#

Je ne voudrais pas écrire tout cela depuis un piédestal : je suis le premier pris dans ces contradictions. Ce que je décris est un chemin, lent et parfois fragile, pas une vertu déjà acquise.

Ce que j’ai changé, ces dernières années :

  • À titre personnel, j’ai quitté Windows pour Fedora Linux. Une de mes filles est passée à Fedora elle aussi.
  • Professionnellement, j’ai fait basculer toute mon équipe sur TuxedoOS (une distribution GNU/Linux). J’ai aussi tenté de faire adopter des ordinateurs Tuxedo, ce que la direction a refusé. La bascule reste fragile : dans mon groupe d’environ 60 personnes, nous ne sommes que 5 sous GNU/Linux.
  • Je me suis fixé une règle simple : chaque euro dépensé en logiciel privateur, je le compense par un euro donné à un projet libre. Concrètement, je contribue financièrement et chaque mois à des projets open source — ce qui double le prix réel de tout logiciel privateur que j’achète directement (je ne compte pas le logiciel embarqué, comme celui de ma voiture, dont j’ignore le coût).
  • Dans mes développements, je n’utilise plus de logiciel privateur : Prothesis Cloud repose presque exclusivement sur du logiciel libre et open source.

Et puis il y a la contradiction que je ne veux pas cacher : je suis salarié d’une entreprise qui développe et opère un SaaS privateur, Prothesis Cloud. Certains me diront que, si je crois vraiment à ce que j’écris, je devrais démissionner. Au-delà du fait que j’ai besoin de ce travail pour faire vivre ma famille, je crois que c’est aussi utile de faire bouger les mentalités de l’intérieur. Avant, personne dans la société ne connaissait les licences libres et leurs spécificités ; on ne développait qu’avec des outils privateurs. Aujourd’hui :

  • on n’apprend plus les technologies fermées : quand on rencontre un problème, on contribue sur les forums (mon score Stack Overflow est passé de 0 à 1 327 ces dernières années — modeste, mais mieux que zéro) ;
  • on a contribué à des projets de l’écosystème .NET (par exemple une amélioration fusionnée dans DocNet) et publié un embryon de bibliothèque en open source, SimpleExcelExporter (sous licence LGPL-3.0) ;
  • on fait tourner PostgreSQL en production : utiliser un projet libre, c’est déjà soutenir sa popularité — et donc, indirectement, l’investissement que des acteurs comme AWS lui consacrent ;
  • l’entreprise est devenue contributrice financière de WeasyPrint, via le collectif CourtBouillon sur OpenCollective — ce que l’on peut vérifier sur son profil OpenCollective.

On entend parfois que les entreprises « exploitent » le logiciel libre. Je crois l’inverse : rien qu’en l’utilisant et en le faisant connaître, on sert la cause — on élargit sa base d’utilisateurs, on remonte des bugs, on aide d’autres développeurs, on finance les mainteneurs.

Mais si ces dix histoires enseignent une chose, c’est que migrer vers le libre après coup est lent, fragile et coûteux. Cinq personnes sur soixante, une direction qui refuse le matériel, des années pour défaire des dépendances accumulées. D’où la vraie leçon, surtout pour celles et ceux qui débutent : commencez libre dès le départ. Le logiciel privateur a souvent de bonnes raisons d’attirer — il est parfois plus abouti, mieux intégré ou mieux accompagné, et c’est un choix qui peut être parfaitement rationnel sur le moment. Mais, après toutes ces années, ma conviction est qu’il reste le plus souvent bien plus facile de bâtir sur du logiciel libre dès le premier jour que de s’extraire, des années plus tard, d’un écosystème privateur dans lequel on s’est enfermé sans même s’en rendre compte.

Conclusion#

Le logiciel privateur est, au sens propre, privateur : il prive l’utilisateur du contrôle de son propre outil de travail. Ce n’est pas une question de méchanceté des éditeurs ; c’est une question de structure de pouvoir. Tant que vous ne possédez ni le code, ni le droit de le modifier et de le redistribuer, c’est l’entreprise technologique qui décide — de la compatibilité, du prix, de la licence, de la date de mort de votre logiciel — et vous n’avez aucun recours.

J’invite donc tout le monde, partout, à se tourner vers le logiciel libre chaque fois que c’est possible, et à privilégier des modèles économiques qui respectent les clients et les utilisateurs plutôt que de les piéger. Et si vous le pouvez, commencez libre dès le départ : s’extraire d’un écosystème privateur des années plus tard coûte bien plus cher que de ne jamais s’y enfermer. Les articles suivants de cette série exploreront concrètement ces alternatives.

Sources et références#

Proposer une modification

Par Yanal-Yves FARGIALLA • Mis à jour le 21 juillet 2026 (Rédaction assistée par IA, révision finale par l'auteur)
Sauf mention contraire, ce contenu est placé sous licence CC BY-SA 4.0. CC BY-SA 4.0