2 points par GN⁺ 2025-10-09 | 1 commentaires | Partager sur WhatsApp
  • Un récit inspiré de faits réels sur les risques du vendor lock-in et des pratiques commerciales agressives
  • Alors que des organismes publics tentaient de migrer leur système de messagerie vers une base open source, ils se sont heurtés à des contrats abusifs et à des soupçons de surveillance de la part du fournisseur
  • Des clauses cachées dans le contrat et des modifications unilatérales ont empêché les clients de partir librement, tout en faisant exploser les coûts de gestion
  • Même lorsque des indices de surveillance et de consultation d’e-mails ont été mis au jour, les organisations se sont davantage préoccupées de la hausse des coûts que d’une réponse juridique ou éthique
  • Même des entreprises se réclamant de l’esprit open source peuvent donner lieu à des cas d’abus, ne laissant au secteur qu’une perte de confiance et une image dégradée

Préface de l’auteur

  • Cette histoire s’appuie sur une expérience réelle, mais des techniques, détails et éléments de contexte ont été modifiés ou mélangés afin de protéger l’identité des personnes et des entreprises
  • Il est recommandé de la lire comme un cas typique illustrant deux problèmes répandus dans l’IT : le vendor lock-in et les pratiques commerciales agressives

Contexte – adoption d’un nouveau système de messagerie

  • Il y a quelques années, un important organisme public (Agency A) utilisait encore un serveur de messagerie Exchange vieillissant
  • Les mises à jour de sécurité n’étaient plus effectuées depuis longtemps, ce qui l’exposait fortement, tandis qu’apparaissaient des règles recommandant l’adoption de solutions open source
  • Un prestataire externe a proposé un service managé fondé sur une stack de messagerie open source, enrichie d’extensions maison et d’un support entreprise
  • Le tarif se situait à un niveau comparable à ce qu’on voit souvent sur le marché, mais il était excessivement élevé au regard du service réellement fourni
  • Agency A disposait déjà d’une infrastructure fiable (plusieurs datacenters, des plages IP robustes, etc.)
  • La demande de l’organisme était de « évaluer cette solution puis migrer si elle convient » (périmètre : environ 500 boîtes mail et alias)

Déploiement pilote et migration réussie

  • L’auteur a déployé cette stack open source à tarif réduit dans un environnement non critique et chez quelques clients pilotes, puis l’a validée pendant un an sans incident
  • Satisfait de sa flexibilité de conception, il a recommandé à Agency A une migration pilote
  • De nouveaux serveurs ont été mis en place, le domaine a été configuré pour les premiers participants, puis la migration a été menée progressivement
  • Après le basculement des enregistrements MX, l’ensemble s’est stabilisé sans difficulté, et l’équipe interne a poursuivi l’exploitation sans problème majeur

La rumeur se répand et un deuxième organisme entre en scène

  • Agency B était déjà cliente du même fournisseur de service managé
  • Voyant des avantages tels qu’une réduction du coût total à un dixième, une meilleure autonomie sur les données et une stabilité accrue, elle s’est intéressée à une migration
  • Mais il restait encore deux ans sur un contrat de cinq ans à renouvellement automatique, avec une clause imposant un préavis de six mois, ce qui laissait une certaine marge de manœuvre
  • En raison de la politique commerciale agressive du fournisseur et de la crainte de représailles, la préparation a été menée dans le plus grand secret
  • Une fois les comptes, alias et jeux de test prêts, la migration réelle a été planifiée pour coïncider avec la notification de résiliation du contrat

Un troisième organisme apparaît et un mauvais pressentiment s’installe

  • Agency C utilisait elle aussi le même fournisseur et souhaitait migrer vers la même stack open source
  • L’auteur a remis à Agency C un devis distinct, sans mentionner son lien avec Agency B
  • Tout semblait se dérouler normalement, jusqu’à la réception inattendue d’un SMS indiquant qu’« il était impossible d’envoyer des e-mails »

Obstruction à la résiliation et soupçons de fuite d’informations internes

  • Le responsable IT d’Agency B a signalé qu’« un problème était survenu dans la résiliation et que les préparatifs de départ internes avaient été révélés au fournisseur »
  • Le fournisseur avait obtenu des informations sur les plans internes de l’organisme, ainsi que sur le devis de l’auteur adressé à Agency C
  • Agency C a même subi des accusations du fournisseur affirmant être « le seul installateur agréé de ce logiciel », assorties de menaces juridiques et de concurrence déloyale
  • Craignant un litige potentiel, l’organisme a abandonné son projet de migration

Soupçons d’interception des e-mails et test

  • Chez Agency C, il a été constaté qu’un compte à authentification par jeton appartenant à un ancien gestionnaire contractuel externe disposait d’un accès à l’ensemble des e-mails
  • Cette personne a reconnu avoir « prévenu » le fournisseur, tout en niant avoir mentionné l’auteur
  • Pour confirmer les soupçons d’interception, un faux devis a été envoyé via une connaissance à l’étranger, après quoi le fournisseur a immédiatement fait référence à son contenu
  • Cela a fortement renforcé la probabilité que les e-mails aient pu être consultés

Clauses contractuelles sidérantes et réponse du fournisseur

  • Lorsque l’équipe IT a protesté officiellement, le fournisseur a répondu que cela était « autorisé par une clause du contrat », en pointant une modification unilatérale acceptée deux ans plus tôt
  • Exemples de clauses modifiées :
    • allongement du délai de préavis de 6 mois à 12 mois
    • possibilité de transformer des services gratuits en services payants
    • blocage des accès autres que le webmail au nom de la « sécurité » (mesure appliquée immédiatement dans les faits)
  • Ce type de pratique était possible à une époque antérieure à l’entrée en vigueur du RGPD, lorsque l’encadrement réglementaire était encore insuffisant

Réaction timide et nouveaux préjudices

  • L’auteur a tenté d’apporter lui-même des clarifications sur la concurrence loyale et la controverse autour de l’installateur non agréé, mais le fournisseur n’a répondu à aucune de ses prises de contact
  • Il a recommandé aux deux organismes d’ouvrir une enquête juridique et éthique, mais dans les faits, leur attention s’est portée uniquement sur la hausse des coûts (fonctionnalités auparavant gratuites devenues payantes, plus 30 % de surcoût)
  • Les organisations ont finalement considéré que seule la charge budgétaire posait problème, plutôt que d’éventuels abus internes ou atteintes aux données personnelles

Conclusion et enseignements

  • Quelques années plus tard, tous les directeurs responsables avaient été remplacés, tandis que seules les équipes techniques restaient, plus prudentes et pleines de regrets
  • L’histoire s’est finalement conclue par une migration vers un fournisseur plus sûr, mais peu innovant
  • L’auteur n’est pas parvenu à résoudre le problème à la racine
  • Lorsqu’une entreprise se réclamant du support open source adopte de telles pratiques de vendor lock-in ou un comportement contraire à l’éthique, c’est tout le secteur qui en subit les conséquences
  • Le cœur du problème n’est pas le logiciel, mais l’attitude de celles et ceux qui le manipulent

1 commentaires

 
GN⁺ 2025-10-09
Commentaires Hacker News
  • Une personne qui avait été autrefois gestionnaire IT par intérim était restée connectée au client mail via une authentification par jeton, avec accès à tous les messages. Cette personne était celle qui avait initialement conclu le contrat avec le fournisseur par le passé. Interrogée de manière informelle, elle a dit avoir pris contact « pour prévenir » et qu’il n’y avait pas vraiment de problème. Ce genre de comportement met vraiment mal à l’aise. À cause des gens qui divulguent quelque chose ou enfreignent les règles, puis disent que « ce n’était rien ». Un Director avec qui je travaille a fait des choses semblables à plusieurs reprises. Dès qu’il découvre un logiciel dans une conférence, il organise aussitôt une démo et propose un contrat. Puis il promet d’abord du travail à une société prestataire qu’il connaît. Comme il n’a en réalité pas l’autorité pour conclure le contrat, il me contacte seulement à ce moment-là. Même après qu’on m’a confié le choix du produit, cela s’est produit encore deux fois. À chaque fois, je travaillais sous un manager différent, mais tous les deux ont simplement dit qu’« il n’y avait aucun problème ». Finalement, on lui a fait remarquer que promettre ainsi du travail et préparer un contrat violait gravement la politique de l’entreprise. Le Director n’en avait cure, disant que c’était une affaire interne et que personne ne pouvait le sanctionner. Plus tard, quand nous avons évalué le produit, celui-ci promettait qu’« il s’améliorerait avec le temps », et toutes les données de l’entreprise partaient simplement dans une IA. Aucune considération pour les règles de sécurité des données d’entreprise. Là encore, le Director a réagi avec désinvolture : « Quel est le problème ? Tout le monde lit les données des autres. » Au final, le service juridique est intervenu et a désactivé les fonctions d’IA. C’est vraiment difficile d’affronter des collègues malveillants ou imprudents comme ceux-là, et encore plus quand ils sont au-dessus de soi dans la hiérarchie. Ils font passer ça pour de simples erreurs et on laisse tout couler sans que personne puisse les sanctionner

    • J’ai travaillé dans deux entreprises du Fortune 100. J’y ai vu à plusieurs reprises, au grand jour, des responsables recevoir des rétrocommissions personnelles de fournisseurs. Après l’avoir signalé publiquement, j’ai cessé d’être invité à plusieurs réunions

    • Ce qu’a fait ce Director ressemble énormément à ce que j’ai vu faire habituellement aux HR Directors. Ils adorent changer tous les 2 ou 3 ans, sans aucune consultation, pour un nouveau logiciel hors de prix de gestion de la performance. Cela dit, leur favori du moment, Lattice, a au moins une UX correcte, alors que le PeopleSoft qu’on utilisait avant était vraiment pénible

  • La demande était simple : « Évaluons cette solution et, si elle convient, migrons. » Pourtant, il a fallu relire le texte plusieurs fois pour bien le comprendre. La solution en question désigne ici uniquement la stack open source, sans le fournisseur mentionné dans le paragraphe précédent. Au départ, j’ai cru que cela incluait aussi le fournisseur, puis les comparaisons ont commencé à se multiplier, ce qui a rendu le tout confus

    • Je n’ai compris ce point, moi aussi, qu’après avoir lu plusieurs paragraphes

    • Intéressant. Moi, c’est précisément à cet endroit que j’ai arrêté de lire

  • Ça fait penser à Oracle. Bien sûr, Oracle gère ce genre de choses de manière bien plus habile, mais je recommande toujours aux gens d’éviter les produits Oracle autant que possible

  • J’aimerais voir arriver le jour où cette histoire sera racontée en citant les vrais noms

    • D’après l’auteur, l’entreprise en question engage très souvent des poursuites judiciaires. Il est naturel de vouloir éviter d’être attaqué personnellement. Même ses propres administrateurs n’essaieraient probablement pas de se battre contre cette entreprise

    • Quelqu’un disait : « J’aimerais qu’un jour les vrais noms soient révélés. » Mais la réponse était que c’est écrit anonymement afin de « protéger la vie privée des personnes et de l’entreprise concernées ». Je me demande si les entreprises ont désormais, elles aussi, un droit à la vie privée, mais je comprends ce sentiment. J’ai travaillé autrefois dans une entreprise qui avait fait quelque chose d’absolument inacceptable lors d’une catastrophe naturelle. Quand j’ai soulevé le problème, j’ai été le seul à être sanctionné, tandis que mes collègues encaissaient en silence. J’ai fini par quitter l’entreprise à la première occasion. Cela remonte déjà à vingt ans, mais coucher cette histoire par écrit n’est pas simple. C’était il y a des décennies, donc on se demande si cela a encore du sens, et l’entreprise a changé de direction comme de nom, alors que reste-t-il vraiment ? C’est pour cela qu’il y a sur mon blog un dead-man's switch qui publiera automatiquement diverses histoires sordides sur plusieurs entreprises, mais je me demande bien ce que cela changerait si quelqu’un les lisait. Cela ne ferait sans doute que provoquer de la colère, ou ce serait vain. Malgré tout, je fais aussi partie de ceux qui, sur HN, réclament toujours la divulgation des vrais noms, donc au fond je suis moi-même contradictoire

    • Malheureusement, ils sont dans l’UE, où, juridiquement comme culturellement, la liberté d’expression ne semble pas vraiment considérée comme primordiale

  • Cette personne semble vraiment travailler dans un environnement « champ de mines ». À chaque pas, quelque chose explose, avec des adversaires puissants en face lien connexe

    • Ce genre d’environnement miné est en fait la réalité du tissu économique italien. L’Italie est dominée par de petites entreprises familiales et de proches, donc ce genre de choses arrive tous les jours. Si cette histoire est vraie, je me demande si l’auteur n’est pas quelqu’un ayant des liens avec la Guardia di Finanza, la police fiscale. C’est un service qui détient pratiquement un droit de vie ou de mort sur les petites entreprises
  • Je confonds peut-être les fuseaux horaires ou les parties impliquées, mais quand je lis que « cette entreprise a proposé une version auto-hébergée et enrichie de fonctions propriétaires », je me demande si cela peut encore être qualifié d’open source

    • Il existe beaucoup de projets de ce type. Par exemple, Gitlab a une Community Edition open source, ainsi que des éditions Premium et Ultimate commercialisées

    • C’est un cas de « respect à la lettre de la loi ». Dans le droit européen, en particulier dans celui de plusieurs pays européens, l’usage de l’open source est souvent imposé dans le secteur public, notamment pour garantir l’interopérabilité, éviter le vendor lock-in, préserver la souveraineté numérique, et au nom du principe « argent public = code public ». Utiliser de l’open source sur les serveurs de quelqu’un d’autre permet techniquement de respecter cette obligation, mais si l’on pense aux vraies raisons d’adopter l’open source — surtout éviter le vendor lock-in — la situation en devient presque absurde

  • Il faut absolument lire attentivement les petites clauses du contrat avant de signer. C’est vrai pour les contrats de consommation ordinaires, mais c’est indispensable dans les contrats commerciaux

    • Même les petits contrats commerciaux ne font pas exception. Dans l’association à but non lucratif dont je fais partie du conseil d’administration, des employés ont comparé des photocopieurs multifonctions de bureau et nous ont apporté un contrat. Ils disaient que tout avait déjà été vérifié et qu’il suffisait de signer, mais certaines clauses étaient sidérantes. Par exemple, si nous annulions pour n’importe quelle raison — même si l’autre partie ne respectait pas le contrat — nous devions immédiatement payer l’intégralité du montant restant. Comme il s’agissait d’une formule de location, le coût total de l’équipement était déjà intégré aux mensualités, tout en restant la propriété du fournisseur. Donc, même en cas d’annulation, l’équipement restait au fournisseur et nous, nous payions tout. En cas de litige, nous devions en plus assumer l’intégralité des frais d’avocat de notre côté. J’ai refusé catégoriquement, et les employés m’en ont voulu pendant près d’un an, en disant que partout ailleurs on signait ce genre de choses

    • Le conseil est de lire les petites clauses avec soin, mais en réalité, d’après ce qu’on voit, cela n’aide parfois pas beaucoup. Les cas où les conditions du contrat sont modifiées « unilatéralement » sans même avertir les parties se multiplient. Dans l’IT, c’est presque devenu banal. Même si vous vérifiez soigneusement les clauses du contrat déjà signé, cela ne sert plus à rien puisqu’elles ont changé entre-temps. Aujourd’hui, si vous recevez au moins un e-mail vous informant d’une modification des conditions, vous pouvez déjà vous estimer chanceux. L’attitude est : que ferez-vous si vous n’êtes pas d’accord ? Sans être juriste, cela semble illégal, mais comme les tribunaux ne sanctionnent pas réellement ce genre de pratique, cela continue encore et encore

    • Il faut intégrer dans le calcul tous les coûts : le temps nécessaire pour interpréter et examiner le contrat, les efforts requis, et les risques en cas de mauvaise compréhension. Vu sous cet angle, il vaut souvent mieux ne pas conclure certains contrats du tout

    • Je me demande comment fonctionne concrètement une « clause de modification unilatérale ». Si les petites clauses ne vous conviennent plus, faut-il alors donner un préavis de résiliation de six mois immédiatement ?

    • J’ai lu le contrat d’inscription à ID.me et j’en ai été choqué. Il exige une renonciation « volontaire » à certains droits de citoyenneté. Du coup, je n’ai aucune envie de l’utiliser. Mais pour se connecter à IRS.gov, il n’y a pas d’autre solution. Pour regarder YouTube, il faut un compte Google. Pour participer au groupe de parents de la classe, il faut accepter les conditions Meta de WhatsApp. Ce genre de situation n’en finit plus

  • Je ne suis pas juriste, mais j’ai l’impression que le simple fait qu’ils aient lu les e-mails et agi en conséquence est manifestement illégal, au point que le contrat lui-même devrait être nul

    • Surtout si cela concerne une administration publique, c’est vraiment choquant. Un prestataire externe qui installe en douce une backdoor sur le serveur mail et espionne les e-mails ? Cela pourrait relever de tout et n’importe quoi, de la corruption jusqu’à des opérations de renseignement étrangères. Si cela s’était passé aux États-Unis, le FBI ou la CIA auraient fait le ménage rapidement parmi ce genre de fournisseurs

    • Oui. Le problème, c’est que résilier signifie ensuite devoir affronter devant les tribunaux une partie extrêmement hostile, qui fera tout pour nous faire payer davantage. Certaines organisations privilégient la sécurité à l’éthique et acceptent simplement le surcoût. D’autres entreprises se battent réellement contre les procès abusifs en matière de brevets ou pour faire annuler des clauses contractuelles déraisonnables. L’organisation de cet exemple, elle, n’était clairement pas de ce genre-là

    • Ce n’est pas un avis juridique, mais je pense qu’il faut absolument rendre les noms publics pour prévenir les autres

  • Je pense que beaucoup de gens sur HN ont vécu des situations similaires. Il y a longtemps, nous préparions discrètement l’arrêt d’un système, alors que notre entreprise et un partenaire partageaient une même base de code. L’un de nos développeurs a laissé dans un commit quelque chose comme « Reversing Migration Script », et moins d’une heure plus tard une confrontation majeure éclatait entre les CEO des deux entreprises. Nous n’avons compris que plus tard que l’autre société surveillait en temps réel ce type de mots dans le code, puis agissait immédiatement au moindre signe que nous envisagions une rupture. En réalité, il s’agissait simplement d’une résiliation légale avant échéance, donc rien d’extraordinaire. Nous avons découvert après coup qu’une telle surveillance existait, ce qui a déclenché en interne une véritable chasse aux sorcières pour savoir « qui était l’espion ». Cela a été une expérience très pénible. On dirait que ce genre de comportement quasi psychopathique est devenu banal aujourd’hui. J’ai l’impression d’être le seul à travailler encore avec une naïveté d’un autre âge, ce qui explique sans doute pourquoi tant d’entreprises veulent n’embaucher que des vingtenaires / semi-plaisanterie

    • J’aimerais bien savoir concrètement comment cette surveillance était mise en place. On peut apprendre de ce genre de cas

    • Dans les endroits susceptibles d’être surveillés, il vaut mieux glisser des noms de variables qui déclenchent très facilement des alertes. Un peu comme dans les blagues d’autrefois sur la NSA

  • C’est présenté comme une « histoire d’horreur inspirée de faits réels », mais je me demande si c’est vrai. Ce serait encore plus intéressant si les détails étaient authentiques

    • Il est explicitement indiqué que « certaines technologies, circonstances et certains détails ont été modifiés ou fusionnés avec d’autres expériences afin de protéger la vie privée ». La logique est similaire à celle des médias qui utilisent de faux noms pour éviter les poursuites en diffamation