Redis bascule en propriétaire : ce que ça dit de notre rapport à l'open source

Quand une brique invisible devient soudainement très visible

Pendant des années, Redis a fonctionné comme le carburant silencieux de milliers d'architectures applicatives. Cache, sessions, files de messages, compteurs temps réel — cette base de données en mémoire était partout, précisément parce qu'elle était fiable, rapide et gratuite. Jusqu'au jour où elle ne l'était plus vraiment.

En mars 2024, Redis Ltd a annoncé le passage de son logiciel phare sous une licence duale restrictive, abandonnant la licence BSD qui avait fait sa réputation. En 2026, les effets de cette décision se font pleinement sentir dans les DSI européennes qui n'avaient pas anticipé le choc.

Ce qui s'est passé, sans enjoliver

Le basculement de Redis vers la *Redis Source Available License* (RSALv2) et la *Server Side Public License* (SSPL) n'est pas tombé du ciel. C'est l'aboutissement d'une tension structurelle qui couvait depuis des années dans l'écosystème open source : comment un éditeur commercialise-t-il un logiciel que les hyperscalers américains revendent comme service managé sans lui reverser un centime ?

AWS ElastiCache, Google Memorystore, Azure Cache for Redis — ces services ont bâti des revenus considérables sur le dos d'un code entretenu par une entreprise qui, elle, devait se financer. Redis Ltd a donc fait ce que MongoDB avait fait avant elle avec la SSPL, ce qu'HashiCorp a fait avec Terraform en 2023 : elle a fermé le robinet aux concurrents commerciaux, tout en maintenant une version utilisable pour les entreprises qui déploient Redis pour leurs propres besoins.

Mais la nuance est justement là où les problèmes commencent.

La nouvelle licence interdit l'utilisation commerciale dans des offres de service. Pour une PME qui utilise Redis en interne pour son application métier, le changement est théoriquement limité. Pour un éditeur SaaS européen qui embarque Redis dans son produit vendu à des clients, la situation est juridiquement beaucoup moins confortable. Et pour ceux qui s'appuyaient sur des distributions cloud tierces construites autour de l'ancienne version open source, le flou persiste.

La communauté open source a répondu rapidement. La Linux Foundation a lancé Valkey, un fork de Redis 7.2 sous licence BSD, soutenu notamment par AWS, Google, Oracle et plusieurs acteurs indépendants. Un fork communautaire sérieux, mais qui pose ses propres questions de gouvernance et de pérennité à long terme.

Ce que ça change concrètement pour une DSI européenne

Première conséquence : la dette de clarté juridique. Combien d'organisations ont un inventaire précis de la version de Redis qu'elles utilisent, de la licence sous laquelle elle a été déployée, et du canal par lequel elles la consomment (hébergement propre, service managé AWS, conteneur Docker tiré d'une image publique) ? La réponse honnête, dans la plupart des ETI et même dans certaines grandes entreprises, c'est : pas assez.

Le changement de licence Redis est une occasion — désagréable, mais réelle — de se poser cette question pour toute la pile logicielle. Pas uniquement pour Redis.

Deuxième conséquence : le coût caché de la migration. Valkey est techniquement très proche de Redis 7.2, la compatibilité est large, et beaucoup d'équipes ont déjà migré sans douleur excessive. Mais « sans douleur excessive » cache du temps ingénieur, des cycles de validation, des tests de non-régression. Ce sont des ressources qui ne sont pas allouées à autre chose. Pour une équipe IT de dix personnes dans une ETI, c'est loin d'être anodin.

Troisième conséquence, plus profonde : la remise en question du modèle de confiance implicite. Pendant vingt ans, l'industrie tech a fonctionné sur un pacte non écrit : certains logiciels fondamentaux resteraient libres parce que leurs créateurs avaient intérêt à construire un écosystème large avant de le monétiser. Ce pacte se fissure. HashiCorp, Redis, Elasticsearch avant eux — ces éditeurs ne sont pas des mauvais acteurs. Ils font face à une pression économique réelle. Mais pour les DSI qui ont bâti leurs architectures sur cette confiance implicite, la leçon est dure à encaisser.

Le problème structurel que Redis révèle

Il serait trop simple de réduire ce sujet à « méfiez-vous des licences open source ». La réalité est plus complexe, et plus inconfortable.

La plupart des DSI européennes ont une dépendance à des logiciels open source américains non pas par négligence, mais parce que ces logiciels étaient objectivement les meilleurs de leur catégorie. Redis était meilleur que ses concurrents. PostgreSQL l'est encore. Linux l'est. Le problème n'est pas l'open source — c'est la concentration de la gouvernance de ces projets dans les mains d'acteurs soumis à des logiques économiques sur lesquelles les utilisateurs européens n'ont aucune prise.

Valkey illustre bien la tension. Le fork est technique, le code est là, les contributeurs sont sérieux. Mais la gouvernance repose sur la Linux Foundation — une organisation américaine — avec comme principaux contributeurs AWS et Google — des entreprises américaines. On a remplacé une dépendance à un éditeur américain par une dépendance à un consortium dominé par des acteurs américains. C'est mieux qu'une licence propriétaire, mais ce n'est pas de l'autonomie.

Cette situation n'est pas propre à Redis. Elle se retrouve dans les bases de données, les outils de monitoring, les frameworks applicatifs, les systèmes de messagerie. La question n'est pas de tout remplacer — ce serait absurde et contre-productif. Elle est de savoir précisément où se situent les points de vulnérabilité critique dans son propre environnement.

Ce que les DSI peuvent faire — pragmatiquement

Avant de parler de souveraineté ou de migration, il y a un travail de fond plus simple et plus urgent : cartographier ses dépendances avec honnêteté.

Cela signifie identifier, pour chaque composant critique de l'infrastructure, trois choses : la licence exacte sous laquelle il est utilisé, le modèle économique de l'éditeur ou du projet, et la profondeur de l'intégration dans l'architecture. Un composant utilisé à la marge, facilement substituable, n'a pas le même niveau de risque qu'une brique sur laquelle reposent dix applications métier.

Cet inventaire n'est pas un projet de six mois. Pour une ETI bien organisée, c'est quelques jours de travail avec les équipes techniques. Mais il faut le faire, et le maintenir à jour.

Ensuite, diversifier les points de contrôle sans tomber dans la paranoïa. Cela peut vouloir dire privilégier les services managés de Valkey chez un hébergeur européen plutôt que le service Redis d'AWS — non pas par idéologie, mais parce que cela réduit la concentration du risque. Des acteurs comme Scaleway ou Infomaniak proposent désormais des services compatibles Redis/Valkey sur infrastructure européenne. Ce n'est pas une garantie absolue, mais c'est une diversification réelle.

Enfin, intégrer la question des licences dans les processus d'achat et de validation technique. C'est peut-être la recommandation la plus banale en apparence, et la plus rarement appliquée. Quand une équipe de développement intègre une nouvelle dépendance open source, qui vérifie la licence ? Qui évalue le modèle économique du projet ? Dans combien d'entreprises cette question est-elle posée systématiquement, et pas seulement après un incident ?

Le cas Redis a au moins un mérite : il rend cette conversation incontournable.

Ce que ça dit de nous, au fond

Le vrai sujet derrière Redis, ce n'est pas Redis. C'est notre rapport collectif à la gratuité dans le logiciel. Nous avons consommé des années d'ingénierie de haute qualité à coût nul, en présupposant que ce modèle était stable parce qu'il avait toujours fonctionné.

Les éditeurs open source qui changent de licence ne sont pas des traîtres. Ils sont des entreprises qui cherchent à survivre dans un marché où les hyperscalers captent la valeur sans partager les coûts de développement. La réponse à ce problème structurel — contribuer financièrement aux projets dont on dépend, participer à leur gouvernance, soutenir des alternatives maintenues en Europe — est connue depuis longtemps. Elle est juste rarement mise en pratique.

La Commission européenne finance des initiatives comme le FOSSA (Free and Open Source Software Audit) pour cartographier et sécuriser les dépendances open source dans le secteur public. C'est une bonne idée. Mais le secteur privé européen, lui, n'a pas encore développé de culture équivalente de contribution et de soutien aux communs numériques dont il dépend.

Redis en 2024, Terraform en 2023, qui sera en 2027 ? La question n'est pas rhétorique. Elle mérite une réponse dans vos comités de direction IT, pas seulement dans les discussions entre architectes.

*L'affaire Redis ne se résume pas à une décision d'éditeur ou à un problème de licence. Elle est un signal sur la fragilité d'un modèle que nous n'avons jamais vraiment examiné. C'est peut-être le bon moment pour le faire.*