À Devoxx Belgium, nous avons lancé un défi aux développeurs : créer et déployer une véritable application, avec une vraie base de données, en une quinzaine de minutes. Un petit coup de pouce de l'IA, une touche belge et quelques LEGO pour la motivation. Voici ce que ça a donné.

Ça fait presque 20 ans que je vais à Devoxx Belgium. C'est une conférence qui compte énormément pour moi, aussi bien personnellement que professionnellement. C'est là que j'ai eu l'idée de créer ce qui allait devenir FinistDevs, là que j'ai commencé à m'imaginer un jour sur scène en tant que speaker, et là aussi que, quelques années plus tard, j'ai découvert que les Developer Relations pouvaient être un vrai métier.

Alors, quand Clever Cloud a décidé de sponsoriser Devoxx Belgium cette année, j'étais particulièrement heureux.

Mais avant de partir pour Anvers, il y avait une question que je me posais : qu'est-ce qu'on pourrait proposer sur notre stand qui soit vraiment intéressant pour les développeurs ?

Bien sûr, on voulait faire découvrir Clever Cloud. C'est quand même une des raisons pour lesquelles les entreprises sponsorisent des conférences de développeurs.

Mais je n'avais pas envie de passer trois jours à expliquer aux visiteurs à quel point c'est facile de déployer une application sur notre plateforme.

Je voulais qu'ils le découvrent par eux-mêmes.

Et c'est comme ça qu'est né le 15-minute Clever Cloud Challenge.

Stop Prompting. Start Shipping.

Le principe était tout simple.

Venez sur notre stand. Ouvrez votre ordinateur. Créez une petite application. Connectez-la à une vraie base de données. Déployez le tout sur Clever Cloud.

Et faites ça en une quinzaine de minutes.

Il n'y avait que quelques règles :

• N'importe quelle stack. JavaScript, Python, Java, Go, ce que vous préférez.
• N'importe quelle IA. Claude, ChatGPT, Gemini, Copilot ou votre agent de code préféré. Peu importe.
• Une petite touche belge. Frites, bière, BD, cyclisme, Magritte, Devoxx lui-même. Tout ce qui pouvait avoir un rapport, même lointain, avec la Belgique.
• Une vraie base de données et un vrai déploiement. Pas une maquette, pas une capture d'écran, pas une application qui tourne uniquement sur votre ordinateur. Quelque chose d'accessible publiquement, avec des données qui persistent réellement.

Et comme les 15 minutes étaient un objectif, pas une raison de pénaliser quelqu'un qui passait un peu plus de temps à déboguer, on n'était pas particulièrement stricts sur le chronomètre.

L'important, c'était de déployer quelque chose.

Nous avions préparé une page dédiée au challenge avec les instructions, un prompt de démarrage à copier dans son assistant IA préféré et un coupon offrant 200 € de crédits Clever Cloud, valables six mois.

Le prompt proposait trois idées de petites applications, aidait le participant à en choisir une, puis l'accompagnait dans le développement, la création de la base de données et le déploiement.

On avait aussi prévu une petite motivation supplémentaire : chaque personne ayant terminé le challenge pouvait participer à un tirage au sort quotidien pour gagner des LEGO. Parce que bon, des LEGO, quoi.

Mais il n'y avait ni jury, ni classement, ni récompense pour l'application la plus sophistiquée. Une toute petite application fonctionnelle avait exactement les mêmes chances de gagner qu'un projet ambitieux.

On n'organisait pas un hackathon, on invitait les développeurs à découvrir une plateforme en l'utilisant vraiment.

40 développeurs. 48 applications déployées.

Et ça a marché.

Pendant les trois jours, 40 développeurs ont créé et déployé une application avec une véritable base de données sur Clever Cloud.

Je voudrais insister un instant sur ce chiffre.

Pas 40 personnes qui ont scanné un QR code. Pas 40 adresses email récupérées sur un stand. Pas 40 coupons distribués.

40 développeurs qui ont réellement construit quelque chose, provisionné une base de données, déployé leur application et sont revenus nous montrer ce qu'ils avaient créé.

Pour moi, c'est un résultat beaucoup plus intéressant que le nombre de personnes passées devant notre stand.

Et le meilleur dans tout ça ? Ce qu'ils ont construit.

Nous avions volontairement laissé le challenge très ouvert. Pas d'application modèle, pas de tutoriel imposé que tout le monde devait suivre.

On donnait aux participants un objectif, quelques contraintes et la liberté d'être créatifs. Les résultats ont été bien plus variés que ce que j'imaginais.

Quelques-unes de mes applications préférées

Impossible de présenter les 48 applications ici, mais j'avais envie de partager quelques-unes de celles qui m'ont particulièrement marqué.

Pas forcément parce qu'elles étaient les plus sophistiquées techniquement, mais parce qu'elles étaient amusantes, originales ou qu'elles exploitaient particulièrement bien les contraintes du challenge.

It's Raining Devs : quand Magritte rencontre Devoxx

Essayer It's Raining Devs

Celle-ci fait probablement partie de mes préférées.

Prenez les tableaux surréalistes de René Magritte, ajoutez une foule de développeurs participant à Devoxx et transformez le tout en une œuvre interactive et collaborative.

Les participants peuvent créer leur propre personnage flottant, choisir ce qui lui cache le visage, lui donner un nom et rejoindre le tableau.

Et ces développeurs ne sont pas de simples éléments affichés temporairement dans un navigateur. Chacun est enregistré dans PostgreSQL sur Clever Cloud.

Il y a même de petites interactions, un appel des participants et des cartes postales à enregistrer ou à partager.

J'adore cette application parce qu'elle combine quelque chose de très belge, une idée vraiment ludique et une base de données qui fait partie intégrante de l'expérience.

Elle illustre aussi quelque chose que j'apprécie particulièrement dans ce genre de challenges : une petite application n'est pas obligée d'être une application ennuyeuse.

Roll for Waffle : laissez les dés décider de votre destin

Créer votre propre gaufre belge

Qu'est-ce qui se passe quand on mélange des gaufres belges et des dés polyédriques, comme ceux qu'on utilise dans les jeux de rôle sur table ?

On obtient Roll for Waffle, et j'adore le résultat.

Le concept est merveilleusement simple : au lieu de choisir les ingrédients de votre gaufre, vous laissez les dés décider.

D'abord, un lancer pour la base de la gaufre. Ensuite, un autre pour la garniture principale. Et enfin, un dernier pour la garniture secondaire.

Chaque lancer s'accompagne d'un joli dé polyédrique animé, et le résultat vient s'ajouter à votre création.

Vous allez peut-être obtenir une classique gaufre de Liège avec de la pâte de spéculoos et des fraises fraîches. Ou alors une combinaison complètement improbable qu'aucun pâtissier belge n'oserait servir.

C'est justement ce qui fait tout le charme du jeu. Vous ne choisissez pas. Les dés ont parlé.

Et une fois votre création terminée, vous pouvez partager votre chef-d'œuvre généré aléatoirement.

En tant que personne ayant passé un nombre absolument déraisonnable d'heures à lancer des dés polyédriques, cette application m'a immédiatement fait sourire.

C'est un exemple parfait de ce que j'ai aimé dans ce challenge : donnez aux développeurs un thème simple, un peu de liberté et l'occasion d'expérimenter, et ils trouveront des idées auxquelles vous n'auriez jamais pensé.

Bon, excusez-moi, j'ai une gaufre à tirer aux dés.

Devoxx Bingo : parce que chaque conférence a ses clichés

Jouer à Devoxx Bingo

Si vous avez participé à suffisamment de conférences de développeurs, vous savez que certaines choses finissent presque toujours par arriver.

Certaines expressions vont être répétées. Certaines technologies vont être mentionnées. Certains moments vont vous sembler étrangement familiers.

Alors pourquoi ne pas en faire un bingo ?

Devoxx Bingo vous propose une grille de clichés de conférence à repérer pendant l'événement. Cochez-les au fur et à mesure que vous les rencontrez et essayez de compléter une ligne.

L'application se présente comme une quête secondaire non officielle, sans le moindre prix à gagner, mais avec le droit de se vanter de sa victoire. Un droit tout à fait discutable, d'ailleurs.

Exactement le genre d'application qui me fait sourire.

Et franchement, j'imagine très bien des gens y jouer pendant une conférence.

Devoxx YouTube Search : retrouver cette conférence dont on se souvient vaguement

Explorer Devoxx YouTube Search

Vous connaissez cette sensation ? Vous vous souvenez d'avoir vu une excellente conférence, mais impossible de retrouver qui la présentait, ou même en quelle année c'était.

Avec presque deux décennies de conférences enregistrées, Devoxx a constitué une incroyable bibliothèque de connaissances techniques sur YouTube. Mais retrouver une session précise n'est pas toujours évident.

C'est là qu'intervient Devoxx YouTube Search.

L'application permet de rechercher des vidéos Devoxx à partir de leurs titres et descriptions, pour retrouver plus facilement des conférences sur les sujets qui vous intéressent.

Ce que j'aime particulièrement ici, c'est le choix du sujet. Alors que beaucoup de participants ont choisi quelque chose de ludique ou de typiquement belge, ce développeur a décidé de créer un outil directement lié à la conférence et à son contenu.

C'est un joli rappel qu'un challenge comme le nôtre ne produit pas uniquement des jeux et des expérimentations. Il peut aussi inspirer des outils qui répondent à de vrais besoins de la communauté.

Et en tant que personne ayant donné pas mal de conférences au fil des années, j'apprécie forcément tout ce qui peut aider les gens à les découvrir !

BelgiQ : à quel point êtes-vous belge ?

Essayer BelgiQ

BelgiQ se présente comme « Le quiz qui a la frite ».

Ça commence déjà bien.

C'est un quiz sur le thème de la Belgique, disponible en français, en néerlandais et en anglais, avec un classement des joueurs.

Mais ce qui rend cette application particulièrement intéressante, c'est que son créateur, Gwenaël Jakab, a partagé son expérience sur LinkedIn.

Gwenaël a choisi de construire BelgiQ avec Node.js, Express et PostgreSQL. Il a utilisé ChatGPT pour préparer son prompt, puis confié l'implémentation et le déploiement à ChatGPT Work.

15 minutes plus tard, il avait une application fonctionnelle. Après 10 minutes supplémentaires à examiner le résultat, demander quelques ajustements et du refactoring, il avait une V2 dont il était satisfait.

Et il n'avait pas écrit lui-même le code de l'application.

Ce que j'ai particulièrement apprécié dans son témoignage, c'est sa vision du rôle du développeur. Même lorsqu'un agent IA prend en charge l'implémentation, il faut toujours quelqu'un pour faire les choix d'architecture, définir les besoins, relire le code et valider le résultat.

C'est une distinction importante, qui se perd parfois dans les discussions autour du développement assisté par IA.

Pour moi, son expérience illustre aussi exactement ce qu'on cherchait à montrer avec ce challenge : permettre aux développeurs de se concentrer sur ce qu'ils veulent construire, tout en découvrant à quel point il peut être simple de le déployer sur Clever Cloud.

Et le mieux dans tout ça ? Vous pouvez essayer BelgiQ vous-même.

Friesdvisor : les vraies questions de la vie

Explorer Friesdvisor

Oubliez les recommandations de restaurants.

On est en Belgique. Il faut parler de frites.

Friesdvisor est un annuaire dans lequel vous pouvez rechercher une friterie ou une ville, et ajouter de nouveaux établissements.

C'est une idée merveilleusement simple, et exactement le genre de référence belge qu'on espérait voir apparaître.

Ce que j'aime particulièrement, c'est que ce n'est pas juste une blague. C'est un concept qui pourrait devenir une petite application communautaire réellement utile.

Et évidemment, il faut bien un endroit où stocker toutes ces friteries.

48 applications et encore plein de créativité à découvrir

Ce ne sont que quelques-unes de mes préférées.

Mais une des choses que j'ai le plus aimées dans ce challenge, c'est l'incroyable diversité des idées. Donnez à 40 développeurs le même point de départ, les mêmes contraintes et une quinzaine de minutes, et vous obtenez 48 interprétations différentes de ce que peut être une petite application.

Certains ont créé des jeux. D'autres des outils pratiques. Certains ont puisé leur inspiration dans la culture belge, tandis que d'autres se sont tournés vers la conférence elle-même.

Et impossible de rendre justice à toutes ces créations dans un seul article.

C'est pour ça que nous avons créé la galerie Built at Devoxx Belgium, dans laquelle vous pouvez découvrir les applications que les participants ont choisi de partager publiquement.

👉 Découvrir la galerie du Clever Cloud Challenge

Allez y faire un tour. Essayez les applications. Découvrez ce que les participants ont imaginé.

Et si l'une d'entre elles vous fait sourire, ou vous donne une idée de quelque chose que vous aimeriez construire vous-même, alors je pense que notre petite expérience aura déjà accompli quelque chose de plutôt chouette.

Qu'est-ce qu'on a appris ?

Plusieurs choses m'ont marqué pendant ces trois jours.

D'abord, les développeurs sont incroyablement créatifs quand on leur donne juste assez de contraintes.

Le thème belge était volontairement vague. On ne voulait pas que les participants passent dix minutes à se demander si leur idée était recevable.

Un plat belge ? Parfait.

Une référence à un artiste belge ? Excellent.

Une blague sur Devoxx ? Évidemment.

Cette petite contrainte créative donnait un point de départ sans imposer ce qu'il fallait construire.

Ensuite, les assistants de développement IA rendent ce genre d'exercice beaucoup plus accessible.

Tout le monde n'arrivait pas avec une idée d'application, un framework préféré ou une connaissance précise de la manière de provisionner et connecter une base de données. Mais avec un peu d'accompagnement, les participants pouvaient passer d'une idée à quelque chose qui tournait en ligne étonnamment vite.

L'expérience de Gwenaël avec BelgiQ illustre un autre point important : le développement assisté par IA ne fait pas disparaître le développeur. Il change la manière dont celui-ci utilise son temps.

Le développeur continue à prendre les décisions, définir les besoins, examiner les résultats et assumer la responsabilité de ce qui est livré. Pendant ce temps, l'agent de code peut prendre en charge une bonne partie de l'implémentation, et la plateforme s'occupe de l'infrastructure.

Bien sûr, l'IA ne faisait pas disparaître magiquement tous les problèmes. Il y avait toujours des questions de déploiement, des soucis de configuration et des moments où quelqu'un avait besoin d'un petit coup de main. C'est aussi pour ça qu'on était là.

Mais la combinaison du développement assisté par IA et d'une plateforme qui prend en charge l'infrastructure permettait de se concentrer sur la partie intéressante : construire et déployer l'application. Et c'est exactement ce qu'on voulait faire découvrir aux participants avec Clever Cloud.

Enfin, cette expérience m'a rappelé quelque chose de fondamental dans les Developer Relations.

Montrer aux gens comment quelque chose fonctionne, c'est utile. Leur permettre de le découvrir par eux-mêmes, c'est encore mieux.

J'aurais pu passer quinze minutes à expliquer comment Clever Cloud gère les déploiements, les bases de données, les variables d'environnement et l'hébergement des applications. À la place, les développeurs ont passé ces quinze minutes à le faire. Et à la fin, ils avaient quelque chose à eux à nous montrer.

Ça change complètement la conversation qu'on peut avoir sur un stand de conférence.

Et maintenant ?

Le challenge ne doit pas forcément s'arrêter à Devoxx.

Tous les participants ont reçu 200 € de crédits Clever Cloud, valables six mois après leur activation. De quoi continuer à expérimenter, améliorer leur application ou commencer quelque chose de complètement différent.

Nous réfléchissons aussi à la manière de prolonger l'expérience avec de nouveaux petits défis, pour encourager les participants à explorer davantage la plateforme.

Et j'aimerais vraiment renouveler cette expérience dans d'autres conférences.

Le thème belge a merveilleusement bien fonctionné à Devoxx Belgium. Imaginez ce que les développeurs pourraient inventer dans d'autres villes ou d'autres pays.

On a déjà quelques idées.

À votre tour. Stop Prompting. Start Shipping !

J'ai participé à énormément de conférences de développeurs au fil des années, des deux côtés du stand. J'ai distribué des stickers, offert des T-shirts, fait des démonstrations, répondu à des questions techniques et eu d'innombrables conversations autour des plateformes cloud. Et j'aime toujours autant tout ça.

Mais voir quelqu'un arriver sur notre stand avec rien de plus qu'une idée, puis revenir un peu plus tard avec une application fonctionnelle déployée sur Clever Cloud ? Ça, c'était particulièrement satisfaisant.

Et découvrir la créativité de ces 40 développeurs a rendu toute cette expérience encore plus intéressante.

Alors, à toutes celles et ceux qui ont participé au challenge à Devoxx Belgium : merci !

Merci d'avoir pris le temps de découvrir Clever Cloud, d'avoir joué le jeu de notre thème belge un peu farfelu et, surtout, de nous avoir montré vos créations.

Envie d'essayer ?

Bonne nouvelle : pas besoin d'avoir participé à Devoxx pour relever le défi !

Le challenge original de Devoxx Belgium est toujours en ligne, et nous avons également créé une version générique de Stop Prompting. Start Shipping. que tout le monde peut essayer, n'importe où.

Le coupon spécial Devoxx de 200 € n'est plus disponible, mais chaque nouveau compte Clever Cloud bénéficie de 20 € de crédits gratuits, largement de quoi créer et déployer une petite application avec une base de données.

Choisissez un thème. Ouvrez votre assistant de développement IA préféré. Donnez-vous 15 minutes.

Construisez quelque chose d'amusant, connectez une base de données et déployez le tout.

Et si vous le faites, j'adorerais vraiment découvrir ce que vous avez imaginé. Partagez votre application avec moi !

Stop Prompting. Start Shipping.

Retour d'expérience d'une responsable conformité.

Il y a quatre ans, en arrivant chez Clever Cloud, je me suis retrouvée face à une culture très technique : pas de suite collaborative, pas d'outil de gestion de projet classique. Tout vit dans GitLab, GitHub et les terminaux.

Or, piloter un SMI (ISO 9001, ISO 27001, HDS, conformité réglementaire), c'est de la formalisation : politiques, procédures, règles de sécurité.

Nous avions donc commencé, classiquement, sur une suite collaborative.

Et très vite, certaines pratiques sont devenues un gouffre chronophage : versionnage à la main dans un tableur, PDF à faire valider en COPIL, signatures, dossiers « validés » et « en cours », liens cassés à chaque changement de format.

Des contrôles humains partout, donc des erreurs probables. Et surtout : les développeurs ne vont jamais dans ces outils. Leur documentation, elle, est dans GitLab.

Alors nous avons fait un choix simple : tout le socle documentaire en Markdown, versionné dans GitLab, au même endroit que la documentation technique.

Ce que ça change concrètement :

• historique complet et natif : commits, diffs, auteurs ;
• chaque modification passe par une Merge Request, avec au moins une approbation d'une personne tierce : la séparation des tâches ne repose plus sur un processus déclaratif, elle est portée par l'outil ;
• la population tech consulte les politiques toute l'année, pas seulement à la sensibilisation annuelle (le nouveau défi, ce sont les profils non tech, qui se forment à GitLab dès l'onboarding, comme moi il y a quatre ans).

Puis nous avons automatisé : un script mensuel lit les changelogs de la plateforme, rédige les mises à jour aux bons endroits des politiques et ouvre les MRs. Il me reste la relecture, puis la validation par la personne experte du sujet. C'est là que le mois devient 30 minutes.

Et le vrai changement est ailleurs : on ne met plus à jour les documents pour l'audit, une fois par an. On met à jour à chaque changement réel du SI. Face à l'auditeur, les sources, les versions et les validations sont sous ses yeux. La conformité devient un état mesuré, pas déclaré.

C'est comme ça que je visualise le compliance as code d'un point de vue gouvernance SMI. Ce que ce fonctionnement change en profondeur, c'est le rythme : la conformité suit celui du système d'information, plus celui du calendrier d'audit.

FoundationDB a rendu cette idée célèbre. Au lieu de s'appuyer seulement sur des tests unitaires et des tests end-to-end sur un vrai cluster, le projet exécute des workloads distribués dans un monde simulé, où le temps, les fautes réseau, les pannes de processus et les décisions d'ordonnancement peuvent être explorés puis rejoués à partir d'une seed. TigerBeetle pousse une discipline complémentaire : rendre les invariants explicites dans le code, vérifier en continu la forme de l'état et transformer une corruption silencieuse en panne locale et bruyante.

Chez Clever Cloud, nous appliquons cette direction à des logiciels d'infrastructure en Rust. Moonpool, développé par Pierre Zemb, donne aux systèmes Rust un environnement de simulation déterministe où le temps, le réseau, les tâches, l'aléa et le stockage peuvent être virtualisés derrière des traits de providers. Magnetar est l'application de cette approche à un client Apache Pulsar. C’est d’ailleurs, l’approche que nous prenons au sein de notre reverse proxy Sōzu. 

Magnetar est un driver Apache Pulsar écrit en Rust, depuis zéro. Il repose sur un coeur protocolaire sans-io, un moteur de production Tokio et un moteur Moonpool pour la simulation déterministe. Cette première release publique s'adresse aux ingénieurs qui veulent essayer Magnetar, évaluer son architecture, comparer son comportement avec les clients Pulsar existants et contribuer à structurer un écosystème Pulsar Rust plus solide.

L'objectif n'est pas seulement d'exposer une API Rust autour de Pulsar. L'objectif est de construire un client dont les comportements difficiles peuvent être inspectés, rejoués et forcés à échouer avant que la production ne s'en charge.

Un client Pulsar fait partie du système distribué

On pourrait être tenté de considérer une bibliothèque cliente comme la partie simple d'un système distribué. Le broker porterait la réplication, le stockage, l'ownership et la coordination. Le client se contenterait de se connecter, d'envoyer des messages, d'en recevoir et de les acquitter.

Cette vision ne tient pas face à un vrai client Apache Pulsar.

Un client Pulsar sérieux doit gérer les producers, consumers, readers, topics partitionnés, consumers multi-topics, subscriptions par pattern, transactions, schémas, authentification, routage proxy, lookup broker, failover de cluster, reconnect, backoff, batching, chunking, ack grouping, suivi des messages non acquittés, negative acknowledgements, retry-letter et dead-letter flows, observabilité et une longue liste de Pulsar Improvement Proposals.

Les bugs difficiles ne viennent pas seulement d'une commande mal encodée. Ils viennent souvent du temps et de l'ordre. Un broker tombe pendant qu'un publish est en vol. Une reconnexion arrive alors qu'un consumer a des acknowledgements en attente. Un refresh de token se produit pendant un reset de session. Un lookup via proxy pointe vers un nouveau broker alors que l'ancienne connexion se vide encore. Un topic migre et le client doit reconstruire assez d'état pour continuer sans prétendre que l'ancienne session existe toujours.

Cela signifie qu'un client Pulsar n'est pas seulement un wrapper pratique autour d'une socket. Il fait partie du système distribué. Il possède un état qui doit rester cohérent pendant que le monde autour de lui change.

Si cet état est caché dans des tâches runtime, des files de channels, des horloges implicites et des accidents de timing, alors le client devient plus difficile à raisonner précisément au moment où cette précision compte le plus. Magnetar part de l'hypothèse inverse : rendre l'état protocolaire explicite, le piloter à travers des frontières étroites et garder l'I/O à l'extérieur.

De l'écosystème Pulsar Rust à Magnetar

Magnetar vient d'une expérience concrète avec l'écosystème Pulsar Rust, notamment la maintenance et l'usage de pulsar-rs. Ce travail compte. Il a donné aux utilisateurs Rust un client Apache Pulsar et a créé le contexte pratique dans lequel l'étape suivante pouvait être évaluée.

Magnetar n'est pas une critique de ce qui existait avant lui. C'est une continuation du même écosystème, avec un point de départ architectural différent. Après avoir travaillé sur des usages Pulsar réels, la direction est devenue plus claire : un driver Pulsar Rust doit rendre la frontière protocole/runtime plus nette, rendre les comportements difficiles reproductibles, suivre la parité explicitement et faire de la testabilité une contrainte de conception.

C'est pourquoi Magnetar ne commence pas par le builder public. Il commence par le protocole.

L'API utilisateur compte, et cette première release expose déjà une surface large. Mais pour un client distribué, la question plus profonde est ce qui se passe sous cette API lorsque le broker bouge, que la connexion tombe, que l'horloge avance, qu'un timeout se déclenche, qu'une subscription est reconstruite ou que la même trace est rejouée sous un autre runtime.

Le coeur sans-io

Le coeur de Magnetar est magnetar-proto. C'est une machine d'état protocolaire synchrone. Elle n'a pas de socket. Elle ne dépend pas de Tokio. Elle ne lance pas de tâches. Elle n'utilise pas async. Elle ne lit pas l'horloge hôte sur le chemin chaud du protocole.

Sa forme suit la même idée générale qui a rendu quinn-proto influent dans le monde réseau Rust : injecter des octets, récupérer des octets à transmettre, récupérer des événements sémantiques et demander à la machine d'état quand son prochain timer expire.

Conceptuellement, l'interface ressemble à ceci :

> connection.handle_bytes(now, bytes);

connection.poll_transmit(&mut out);
connection.poll_event();
connection.poll_timeout();

Cette petite forme est un grand choix d'architecture.

handle_bytes permet à un moteur d'injecter les octets du wire dans la machine d'état. poll_transmit draine les frames sortantes. poll_event produit les événements sémantiques auxquels le runtime doit réagir : challenges d'authentification, résultats de lookup, checksum mismatch, signaux de reconnexion ou transitions protocolaire. poll_timeout permet au runtime de savoir quand réveiller la machine d'état.

La machine d'état ne décide pas d'où viennent les octets. Elle ne sait pas si le réseau est un vrai stream TCP, un stream TLS, un pipe d'octets dans un simulateur ou un broker scripté dans un harnais différentiel. Elle ne décide pas non plus ce que "maintenant" veut dire. Le moteur lui passe le temps.

Les traits publics de magnetar-proto suivent la même règle. Ce ne sont pas des services runtime cachés derrière des callbacks async. Ce sont de petits contrats protocolaires, placés aux endroits où la machine d'état a besoin d'une décision ou d'une transformation : AuthProvider produit les octets d'authentification, Schema définit l'encodage, le décodage, les données de schéma et les hooks de schéma résolu par le broker, MessageEncryptor et MessageDecryptor décrivent la crypto de payload sur des octets et de la metadata de message, ServiceUrlProvider expose l'URL de service courante pour le failover, et HealthProbe utilise un contrat de type poll au lieu d'attacher le crate protocolaire à un runtime async. Le motif est volontaire : le coeur protocolaire peut demander des faits, des octets ou un état de readiness, tandis que l'I/O, le cache, le refresh, les probes réseau et le scheduler restent à l'extérieur.

Cette séparation n'est pas seulement une affaire de propreté. C'est ce qui rend le protocole testable sans broker, sans socket et sans runtime async. Un bug protocolaire peut être réduit à une fixture : injecter ces octets à cet instant, récupérer ces sorties, vérifier cet event stream et rejouer la même séquence.

Pour un client Apache Pulsar, cela compte parce que le protocole wire ne se limite pas au chemin heureux. Il comprend la création de producers, la subscription de consumers, les acks, nacks, transactions, erreurs broker, redirects, challenges d'authentification, migrations de topics, markers de replicated subscriptions, metadata de schémas, batching, chunking et chemins de fermeture. Chacun de ces éléments porte de l'état. Chaque transition d'état est plus facile à raisonner lorsqu'elle n'est pas mélangée aux lectures de socket, au scheduling de tâches et aux wakeups spécifiques d'un runtime.

L'interdiction des channels comme contrainte d'architecture

Magnetar fait aussi un choix Rust async peu courant : les primitives de channels sont interdites dans le workspace.

L'architecture directe d'un client réseau ressemble souvent à ceci : future producer vers channel, channel vers driver task, driver task vers channel, channel vers future consumer. Cela peut fonctionner, mais cela disperse l'état entre des files et des tâches. La backpressure devient implicite. Les sémantiques de fermeture dépendent de la bibliothèque de channel. Des futures abandonnées peuvent laisser des messages dans des endroits difficiles à inspecter. La question de debug devient : où est passé ce message ?

Magnetar utilise un autre motif. L'état vit dans la machine d'état protocolaire et dans la connexion partagée détenue par le runtime. Les futures utilisateur enregistrent des wakers dans des slabs indexés par identifiants d'opération. Le driver possède la boucle d'I/O, injecte les octets dans la machine d'état, draine les frames sortantes et réveille les futures correspondantes lorsque les outcomes arrivent.

Ce n'est pas une interdiction esthétique des channels. C'est une manière de garder la propriété de l'état explicite. Lorsque le driver reconstruit des producers après une reconnexion, lorsqu'un consumer attend un message, lorsqu'un ack outcome est livré ou lorsqu'une opération en attente échoue parce qu'une session a disparu, l'état pertinent est dans la machine d'état et peut y être inspecté.

Ce design a des compromis. Il met plus de pression sur la correction de la machine d'état. Il impose un ordre de locks précis. Il demande aux reviewers de comprendre l'enregistrement des wakers et les chemins de réveil. Mais il rend aussi le comportement beaucoup plus facile à simuler, rejouer et comparer entre runtimes.

Deux moteurs, une machine d'état

Magnetar livre deux moteurs qui pilotent le même coeur protocolaire.

Le moteur par défaut est magnetar-runtime-tokio. C'est le chemin d'exécution de production : TCP, TLS via tokio-rustls, tâches driver, temps réel, vraies sockets et surface publique PulsarClient que la plupart des utilisateurs rencontreront en premier.

Le second moteur est magnetar-runtime-moonpool. Il pilote la même machine d'état magnetar-proto::Connection à travers des providers Moonpool. Au lieu d'inscrire le runtime en dur, Moonpool expose des traits de providers pour le réseau, le temps, le spawning de tâches, l'aléa et le stockage. Avec un bundle de providers proche de la production, le moteur peut exécuter de vraies I/O. Avec des providers de simulation, ces mêmes catégories peuvent être virtualisées.

C'est là que la simulation déterministe devient pratique. Le client peut être piloté dans un monde où le temps avance sous contrôle, où les livraisons réseau peuvent être réordonnées ou interrompues, où les tâches s'exécutent sous un scheduler déterministe, où l'aléa est seedé et où les pannes peuvent être rejouées depuis la même seed.

Moonpool n'est pas un mock. Un mock remplace généralement un composant par un comportement simplifié. C'est utile pour beaucoup de tests unitaires, mais ce n'est pas la même chose que d'exercer un vrai client dans des interleavings difficiles.

Moonpool n'est pas non plus un test end-to-end classique. Un e2e exécute le vrai système, ce qui est indispensable, mais il utilise souvent du temps réel, un vrai réseau et des pannes difficiles à reproduire une fois le timing passé.

Moonpool occupe un autre espace. Il garde le code proche du chemin réel d'exécution tout en virtualisant les providers qui rendent le comportement distribué difficile à reproduire. Le but n'est pas d'éviter les e2e. Le but est d'ajouter un régime où les pannes ne sont plus des anecdotes. Elles deviennent des seeds.

Le moteur Moonpool de Magnetar utilise la même machine d'état protocolaire que le moteur Tokio. Le chemin TLS est lui aussi piloté de façon à préserver la frontière de simulation : au lieu de s'appuyer sur tokio-rustls, le moteur Moonpool pilote directement rustls::ClientConnection au-dessus du pipe d'octets. Cela maintient les handshakes TLS sous le même contrôle déterministe que le reste du réseau simulé.

Tests différentiels : faire converger les moteurs

Deux moteurs ne sont utiles que s'ils ne deviennent pas silencieusement deux clients différents.

Magnetar inclut donc un harnais différentiel. Il exécute une trace, par exemple connect, open producer, send, subscribe, receive, ack, seek et close, contre les moteurs Tokio et Moonpool, puis compare les event streams visibles par l'utilisateur.

Cela compte parce que le moteur Moonpool sert à trouver des bugs difficiles à exposer avec du temps réel et de vraies sockets. Pour que cette recherche ait du sens, le moteur simulé doit rester aligné avec le moteur de production à la frontière utilisateur.

Si Tokio et Moonpool divergent, le simulateur devient moins fiable. Si le harnais différentiel les maintient alignés, alors une seed rouge dans le monde simulé pointe beaucoup plus probablement vers une propriété réelle du client, et non vers une implémentation séparée réservée aux tests.

C'est aussi pour cela que la politique de validation de Magnetar est stricte sur la couverture cross-runtime. Les changements comportementaux doivent exercer la couche sans-io, le runtime Tokio, le runtime Moonpool, l'équivalence différentielle et la surface e2e lorsque c'est applicable. C'est plus de travail qu'un seul test unitaire. C'est aussi le coût pour faire de la simulation déterministe un vrai outil d'ingénierie, pas une expérience annexe.

La parité Java comme contrat de crédibilité

La simulation ne remplace pas la largeur fonctionnelle. Elle rend cette largeur moins fragile.

Apache Pulsar possède un client Java mature, et pour beaucoup d'utilisateurs ce client définit ce que signifie "un client Pulsar". Le produce/consume de base ne suffit pas. Un client crédible doit couvrir les comportements sur lesquels les applications s'appuient : batching, compression, transactions, schémas, topics partitionnés, consumers multi-topics et par pattern, retries, dead-letter flows, providers d'authentification, support proxy, failover, opérations admin et PIPs qui structurent les usages modernes de Pulsar.

Magnetar suit la parité avec le client Java comme un contrat public. Le README porte la matrice de parité et le statut moteur par moteur. L'article n'a pas besoin de recopier cette matrice, mais son existence est importante. Elle donne aux utilisateurs un moyen d'évaluer le projet comme client Pulsar, et non comme une expérience étroite autour d'un seul chemin heureux.

C'est pourquoi la première release publique de Magnetar est plus large qu'une démo minimale. Elle inclut la fondation protocolaire, la façade publique, les moteurs runtime, le support admin, les providers d'authentification, la crypto de messages, le travail CLI, les hooks d'observabilité et une liste croissante de surfaces PIP.

La raison de suivre la parité est simple : les utilisateurs ne choisissent pas une bibliothèque cliente uniquement parce que son architecture interne est élégante. Ils la choisissent parce qu'elle peut représenter le système qu'ils exécutent réellement. L'architecture rend cette surface maintenable. La parité la rend utile.

Au-delà de la production et de la consommation

L'expression "client Pulsar" peut masquer une large surface fonctionnelle. Vus de l'extérieur, les premiers exemples paraissent généralement modestes : construire un client, créer un producer, envoyer un payload, souscrire avec un consumer, recevoir un message, l'acquitter. Ces exemples sont utiles parce qu'ils montrent le point d'entrée. Ils ne suffisent pas à évaluer le client.

Les vraies applications Pulsar dépendent de comportements qui n'apparaissent qu'une fois la première démo fonctionnelle. Un producer peut avoir besoin de batching, de compression, de chunking, de modes d'accès, de sequence ids, de timeouts d'envoi, de propriétés par message, de transactions, d'interceptors et de statistiques de latence. Un consumer peut avoir besoin de batch receive, d'acquittements cumulatifs, d'acquittements par index de batch, de nack backoff, de gestion des timeouts d'ack, de retry topics, de dead-letter topics, de seek, de pause/resume, de modes de souscription et de comportements par partition. Les applications avec des schémas stricts ont besoin d'Avro, de JSON, de Protobuf, de Protobuf-native, de KeyValue, de schémas primitifs et de la sémantique de résolution de schéma côté broker. Les déploiements avec des exigences de sécurité ont besoin d'authentification par token, de mTLS, d'OAuth2, de SASL, de Kerberos/GSSAPI, d'Athenz, de choix de provider TLS, et d'un moyen de raisonner sur le comportement de la crypto sans forcer chaque build à embarquer tous les providers.

Ces fonctionnalités ne sont pas des cases à cocher indépendantes. Elles interagissent. Le batching interagit avec la compression et les timeouts d'envoi. Le chunking interagit avec les sequence ids et la redélivrance. Les transactions interagissent avec les acquittements. La reconnexion interagit avec les producers, les consumers, les lookups, le routage proxy et le failover. L'observabilité doit décrire le comportement sans laisser fuiter de secrets ni noyer les opérateurs en période de churn.

C'est pourquoi le travail fonctionnel et le travail d'architecture de Magnetar sont liés. Plus la surface devient complète, plus il est important que l'état protocolaire soit explicite et que la frontière avec le runtime reste étroite. Un client large bâti sur un état accidentel devient plus difficile à maintenir à mesure qu'il devient plus utile. Un client large bâti sur un état rejouable donne aux mainteneurs une meilleure chance d'empêcher la croissance fonctionnelle de se transformer en comportement caché.

La validation comme architecture

La stratégie de test de Magnetar est volontairement stratifiée, parce que chaque couche attrape une classe différente de bugs.

La couche sans-io permet de tester le comportement protocolaire sans sockets ni tâches async. La documentation de test du projet mentionne aujourd'hui plus de 270 tests unitaires dans magnetar-proto. Ces tests exercent directement la machine d'état : octets en entrée, événements en sortie, buffers de transmission en sortie, transitions d'état vérifiées.

Les tests d'intégration runtime exercent la colle que les tests purement protocolaires ne peuvent pas couvrir. Les moteurs Tokio et Moonpool ont chacun leur surface d'intégration, et le projet impose une parité runtime afin qu'un moteur ne prenne pas silencieusement du retard sur l'autre.

Le pack de chaos déterministe cible les ordonnancements de panne qui ont motivé l'architecture : reconnect, failover, timers en horloge virtuelle, ordre des handshakes TLS, publishes en vol, migration de broker et comportements réseau adversariaux. La documentation du moteur Moonpool décrit un sweep Moonpool quotidien avec 128 seeds aléatoires fraîchement générées en parallèle. Le chiffre compte moins que ce qu'il représente : le client est poussé dans des ordonnancements qu'un humain n'écrirait pas à la main.

Les tests d'équivalence différentielle comparent les deux mondes runtime. Ils posent une question directe : si la même trace est exécutée dans Tokio et Moonpool, l'utilisateur observe-t-il le même comportement ?

Les tests end-to-end restent nécessaires. Ils gardent Magnetar honnête face à un vrai broker Apache Pulsar. La simulation rend des pannes reproductibles, mais elle ne remplace pas la compatibilité avec le système que les utilisateurs déploient.

Ensemble, ces couches ne sont pas une cérémonie. Elles font partie de l'architecture. Le but n'est pas d'accumuler de grands nombres de tests. Le but est d'appliquer la pression de validation exactement là où les clients distribués échouent : état protocolaire, frontières runtime, logique de reconnexion, timing, équivalence et comportement face à un vrai broker.

Ce que la reproductibilité change concrètement

La valeur pratique de la simulation déterministe n'est pas seulement de rendre les tests plus sophistiqués. Elle change la boucle de debug.

Lorsqu'un test end-to-end traditionnel échoue à cause du timing, la première question est souvent de savoir si l'échec est reproductible. S'il ne l'est pas, on ajoute des sleeps, des logs, des timeouts plus larges ou des boucles de retry. Certaines de ces modifications sont utiles. Beaucoup ne font que déplacer la panne ailleurs. La panne reste une histoire : "on l'a vue une fois en CI".

Avec une simulation déterministe, la panne doit devenir un artefact. Cet artefact est une seed, une trace et une transition d'état rejouable. La question passe de "peut-on la refaire apparaître ?" à "quel invariant cet ordonnancement a-t-il violé ?"

Cette différence compte pour une bibliothèque cliente. Les bugs de client se trouvent souvent à la frontière entre le code utilisateur et le broker. Ils sont faciles à attribuer au mauvais endroit. Un publish peut échouer parce que le broker a fermé la connexion, parce que le client a perdu un outcome, parce que le chemin de reconnexion a reconstruit le producer trop tard, parce qu'un ack a réveillé le mauvais waiter, parce qu'un timeout a frappé un état de session périmé, ou parce que la tâche runtime est morte après que le protocole a déjà changé d'état.

Si tout ce comportement est dispersé entre des tâches, des channels, des timers et des sockets, un rapport de panne est difficile à réduire. Si la machine d'état protocolaire est explicite, si la frontière runtime est étroite et si la même séquence peut être rejouée avec des providers contrôlés, le rapport devient beaucoup plus petit : cette seed, cette trace, cet ordre d'événements, cet invariant.

C'est pourquoi Magnetar traite la reproductibilité comme une partie du design du client. Le but n'est pas seulement de trouver plus de bugs. Le but est que les bugs trouvés coûtent moins cher à comprendre et soient plus sûrs à corriger.

Cela change aussi la revue de code. Un reviewer peut demander si un comportement est couvert à la bonne couche. Est-ce une transition protocolaire pure ? Alors le test sans-io doit injecter des octets et vérifier des événements. Est-ce de la colle runtime ? Alors Tokio et Moonpool doivent avoir une couverture équivalente. Est-ce un comportement observable partagé par les deux moteurs ? Alors le harnais différentiel doit comparer les event streams. Est-ce de la compatibilité broker ? Alors un e2e doit toucher un vrai broker Pulsar.

Ces questions sont plus précises que "a-t-on ajouté des tests ?" Elles relient le test au modèle de panne.

Par où commencer la lecture

Pour les ingénieurs qui découvrent Magnetar, le meilleur point d'entrée n'est pas un fichier unique. C'est la relation entre les documents et le code.

Le README donne la surface publique : ce que le client expose, quelles fonctionnalités sont implémentées, comment la matrice de parité Java est suivie, quels PIPs sont supportés et comment les deux moteurs sont positionnés. C'est le contrat utilisateur.

Le document d'architecture explique la forme située sous ce contrat. Il montre la topologie de crates, le sens des dépendances, la frontière sans-io, la boucle driver, le modèle d'événements, les chemins producer et consumer, les moteurs runtime, les sites TLS, les schémas, la couverture PIP et la stratégie de validation. C'est la carte du système.

La série d'ADR explique pourquoi le système a cette forme. ADR-0004 documente la séparation sans-io. ADR-0003 documente l'interdiction des channels. ADR-0011 documente l'injection d'horloge. ADR-0010 documente la décision de parité Java. ADR-0019 documente la relation entre le moteur de production Tokio et le moteur Moonpool par rapport à cet objectif de parité. ADR-0024 documente la politique de test cross-runtime.

Cela compte parce que Magnetar n'est volontairement pas seulement un dépôt de code. C'est un ensemble de décisions d'ingénierie avec une trace publique. Si vous n'êtes pas d'accord avec le design, les ADR donnent la bonne surface de discussion. Si vous voulez contribuer une fonctionnalité, la matrice de parité et la politique de validation indiquent ce que "terminé" veut dire. Si vous voulez évaluer le travail de simulation, la documentation du moteur Moonpool et le harnais différentiel montrent comment le même coeur protocolaire est piloté dans plusieurs mondes.

Cette première release doit donc se lire de deux manières. Comme utilisateur Pulsar, regardez la surface cliente et la matrice de parité. Comme ingénieur infrastructure Rust, regardez la frontière de machine d'état et la stratégie de simulation. Ce qui rend Magnetar intéressant, c'est que ces deux lectures sont censées se renforcer.

Ce que donne la première release publique

Cette première release publique est un point d'entrée technique. Elle s'adresse aux ingénieurs qui veulent essayer Magnetar, lire l'architecture, inspecter les ADR, comparer le comportement avec les clients Pulsar existants et contribuer à structurer l'écosystème Pulsar Rust.

L'API cliente de haut niveau commence par une forme attendue :

let client = PulsarClient::builder()
    .service_url("pulsar://localhost:6650")
    .build()
    .await?;

let producer = client
    .producer("persistent://public/default/orders")
    .create()
    .await?;

Cette API est importante, parce que le client doit être utilisable. Mais la release est aussi une invitation à inspecter les couches inférieures. Lire le README pour la matrice fonctionnelle. Lire le document d'architecture pour le design sans-io. Lire les ADR pour les décisions derrière l'interdiction des channels, les moteurs remplaçables, l'injection d'horloge, la parité Java, la parité Moonpool, les choix de providers TLS et la validation cross-runtime. Lire la documentation du moteur Moonpool si la simulation déterministe appliquée à un vrai client réseau vous intéresse.

Le point important pour cet article est la direction : Magnetar est public pour que les ingénieurs puissent évaluer à la fois la surface cliente et le modèle d'ingénierie qui la porte.

Vous pouvez consulter la première release publique de Magnetar v1.0.0, ainsi que la dernière release à ce jour, la version v1.2.0. 

Pourquoi cela dépasse Magnetar

Magnetar est un client Apache Pulsar. C'est aussi un exemple concret de la manière dont nous voulons construire davantage de logiciel d'infrastructure en Rust.

Les systèmes distribués échouent par transitions d'état. Certaines de ces transitions sont évidentes et faciles à tester. Beaucoup ne le sont pas. Elles apparaissent lorsque le temps avance au mauvais endroit, lorsqu'un retry chevauche un chemin de fermeture, lorsqu'un broker coupe une connexion après avoir accepté une partie de la session, lorsqu'un callback est enregistré juste après une notification, ou lorsqu'un chemin de reconnexion reconstruit un handle mais pas un autre.

On peut essayer de traquer ces bugs après coup. C'est parfois inévitable. Mais l'architecture peut rendre cette traque plus facile ou plus difficile.

Un client avec un coeur protocolaire pur, des événements explicites, du temps injecté, une I/O remplaçable, des seeds déterministes et une comparaison cross-runtime donne de meilleurs outils aux ingénieurs. Il permet de réduire une panne à une trace. Il permet de rejouer cette trace. Il permet de demander si une panne simulée correspond au runtime de production. Il permet d'ajouter un invariant là où une dérive silencieuse de l'état pouvait se cacher.

C'est la direction prise par Magnetar. Rendre le protocole explicite. Rendre le runtime remplaçable. Rendre les pannes reproductibles. Faire de la correction quelque chose que le code doit démontrer en continu.

Merci à Pierre Zemb pour Moonpool et pour cette direction de simulation déterministe en Rust, ainsi qu'aux contributeurs et mainteneurs de l'écosystème Pulsar Rust dont le travail a rendu l'étape suivante possible.

Magnetar est open source. Le code, les notes d'architecture, les ADR et la documentation vivent sur github.com/CleverCloud/magnetar.

Références

Magnetar

• Dépôt Magnetar. Dépôt public du client Apache Pulsar Rust. https://github.com/CleverCloud/magnetar
• README Magnetar. Surface publique, matrice de parité Java, PIPs supportés, couverture par moteur et statut. https://github.com/CleverCloud/magnetar/blob/main/README.md
• Architecture Magnetar. Rationale sans-io, topologie de crates, driver loop, machine d'état protocolaire et tests. https://github.com/CleverCloud/magnetar/blob/main/ARCHITECTURE.md
• Index de documentation Magnetar. Moteur Moonpool, testing, CLI, observabilité, logging, features PIP. https://github.com/CleverCloud/magnetar/blob/main/docs/README.md
• Documentation du moteur Moonpool. Moteur de simulation déterministe, chaos pack, harnais différentiel, modèle de providers. https://github.com/CleverCloud/magnetar/blob/main/docs/moonpool-engine.md
• Documentation de test. Catégories de tests et commandes de validation. https://github.com/CleverCloud/magnetar/blob/main/docs/testing.md
• ADR-0004. magnetar-proto sans-io et moteurs d'I/O remplaçables. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0004-sans-io-protocol-core.md
• ADR-0010. Parité complète avec le client Java. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0010-v0-1-full-java-parity.md
• ADR-0024. Politique de tests et couverture cross-runtime. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0024-cross-runtime-test-and-coverage-policy.md

Écosystème

• pulsar-rs. Client Apache Pulsar Rust existant. https://github.com/streamnative/pulsar-rs
• Apache Pulsar. Plateforme distribuée de messaging et streaming. https://pulsar.apache.org/
• Client Java Apache Pulsar. Surface de référence pour de nombreux utilisateurs Pulsar. https://pulsar.apache.org/docs/

Simulation déterministe

• FoundationDB testing. Lignée de la simulation déterministe et de l'injection de fautes. https://apple.github.io/foundationdb/testing.html
• TigerBeetle TigerStyle. Style d'ingénierie centré sur les assertions. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md
• TigerBeetle VOPR. Approche de simulation testing. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/internals/vopr.md
• Dépôt Moonpool. Simulation déterministe pour systèmes Rust, développée par Pierre Zemb. https://github.com/PierreZ/moonpool
• moonpool-sim. Crate du moteur de simulation Moonpool. https://crates.io/crates/moonpool-sim

C'est une fonction distincte de la conteneurisation elle-même, qui consiste à empaqueter une application avec ses dépendances dans un format standard. Les différences entre Docker et Kubernetes reposent précisément sur cette distinction : Docker fabrique et exécute les conteneurs, Kubernetes les orchestre. Aujourd'hui, Kubernetes est l'orchestrateur de référence, mais l'orchestration en tant que concept existe indépendamment de l'outil qui la met en œuvre.

Pourquoi l'orchestration existe ?

Faire tourner trois conteneurs sur un serveur ne demande pas d'orchestration. On démarre, on supervise à l'œil, on redémarre à la main si quelque chose plante. Le problème change de nature à partir du moment où une application devient un système distribué : plusieurs services, plusieurs machines, du trafic variable, des déploiements fréquents. Les questions opérationnelles qui apparaissent alors sont concrètes. Sur quelle machine placer ce nouveau conteneur ? Que faire si un nœud tombe la nuit ? Comment passer de la version 1.4 à la 1.5 sans interruption visible ? Comment un service interne en trouve un autre quand les adresses IP changent à chaque redémarrage ?

Chacune de ces questions a une réponse manuelle possible, scriptable même. L'orchestration consiste à les automatiser de manière cohérente, sous un modèle unique.

Les cinq fonctions principales de l'orchestration

Kubernetes traite ces questions via un modèle déclaratif construit sur des boucles de réconciliation : on décrit l'état souhaité du système, et l'orchestrateur compare en permanence cet état désiré à l'état réel pour les rapprocher. Les cinq fonctions qui suivent sont des instanciations de ce mécanisme général.

Scheduling : placer les conteneurs sur les bonnes machines

Le scheduling répond à une question : quand un nouveau conteneur doit démarrer, sur quelle machine du cluster doit-il s'exécuter ? Sur un cluster de quelques nœuds aux profils homogènes, la décision est triviale. Sur un cluster réel, elle ne l'est pas : certaines machines ont du GPU, d'autres pas, certaines sont déjà chargées, certaines applications doivent être isolées, d'autres doivent au contraire être co-localisées pour des raisons de latence.

Le composant kube-scheduler effectue ce choix en deux étapes : filtering, qui élimine les nœuds qui ne peuvent pas accueillir le pod (capacité insuffisante, contraintes d'affinité, taints et tolerations), et scoring, qui note les nœuds restants selon plusieurs critères. Le pod est ensuite assigné au nœud retenu via une opération de binding auprès de l'API server. La qualité de la décision dépend des informations fournies au scheduler. Ce sont les requests de ressources déclarées sur les pods qui déterminent le placement : le scheduler cherche un nœud dont la capacité disponible couvre ces requests. Les limits, elles, ne servent pas au placement mais plafonnent la consommation d'un conteneur une fois qu'il tourne.

Scaling : ajuster la capacité au trafic réel

Le scaling automatise une décision simple à formuler : combien de copies d'un service doivent tourner à un instant donné ? Trop de copies coûte cher. Trop peu provoque des incidents au moindre pic.

Le scaling est une fonction commune à tous les orchestrateurs ; les mécanismes varient selon l'implémentation. Dans Kubernetes, il repose sur trois briques distinctes. Le Horizontal Pod Autoscaler (HPA), inclus dans le cœur de Kubernetes, ajuste le nombre de pods d'un déploiement en fonction d'une métrique. Il s'appuie pour cela sur le Metrics Server, un composant à installer séparément, car la collecte de métriques n'est pas fournie par défaut. Le Vertical Pod Autoscaler (VPA), livré lui aussi comme projet séparé, ajuste les ressources allouées à chaque pod. Le Cluster Autoscaler, enfin, ajoute ou retire des nœuds entiers selon les besoins agrégés. Ces mécanismes supposent des métriques fiables : un HPA piloté sur le CPU, alors que le service est en réalité contraint par les I/O disque, ne produit pas le résultat attendu.

Self-healing : remplacer ce qui tombe

À partir d'un certain nombre de machines, les pannes ne sont plus des événements exceptionnels mais une donnée d'arrière-plan. Un disque défaille, un kernel panic survient, un conteneur fuit de la mémoire et finit OOM-killed. Sans orchestration, chaque panne déclenche une intervention humaine, plus ou moins urgente. Avec orchestration, ces événements sont absorbés sans intervention.

Au sein de Kubernetes, le mécanisme repose sur deux éléments. D'abord, des sondes (liveness, readiness, startup) qui lui  permettent de savoir si un conteneur fonctionne réellement, et pas seulement s'il a démarré. Ensuite, le principe que tout objet géré par un controller (Deployment, StatefulSet, DaemonSet) est en permanence comparé à l'état désiré : si un pod disparaît, le controller en demande un nouveau. La précision des sondes conditionne la qualité du self-healing : des sondes trop strictes provoquent des redémarrages inutiles, des sondes trop laxistes laissent passer des conteneurs cassés.

Service discovery et load balancing interne

Dans un parc de conteneurs en mouvement, où chaque pod a une adresse IP éphémère, deux services qui doivent communiquer ne peuvent pas s'appuyer sur des configurations IP statiques. Le service discovery résout ce problème par une couche d'indirection. Dans Kubernetes, un objet Service regroupe un ensemble de pods (sélectionnés par labels) sous un nom DNS stable et une IP virtuelle. CoreDNS, le serveur DNS interne du cluster, résout ces noms. Le trafic envoyé à l'IP du Service est distribué entre les pods prêts via kube-proxy. Ce principe n'est pas propre à Kubernetes : d'autres orchestrateurs répondent au même besoin autrement. Sur Clever Cloud, par exemple, les services se découvrent via l'injection de configuration entre applications et via les Network Groups, un réseau privé chiffré doté d'une résolution DNS interne.

Plusieurs types de Services existent (ClusterIP pour l'interne, NodePort et LoadBalancer pour l'externe), auxquels s'ajoute la notion d'Ingress pour le routage HTTP au niveau applicatif. Cette couche réseau, simple en apparence, contient une part substantielle de la complexité d'exploitation de Kubernetes : choix du plugin CNI, politiques réseau, observabilité du trafic est-ouest.

Rolling updates et rollbacks

Mettre en production une nouvelle version sans interrompre le service est une opération risquée si elle est faite à la main. Kubernetes la traite comme une transition d'état : on modifie le manifeste du Deployment pour pointer vers la nouvelle version d'image, et le controller applique la stratégie de rollout configurée.

La stratégie RollingUpdate (par défaut) remplace progressivement les anciens pods par des nouveaux, en garantissant qu'un nombre minimal reste disponible à tout moment. La stratégie Recreate arrête tout puis redémarre, utile pour des migrations de schéma incompatibles. En cas d'échec, le rollout ne revient pas seul à l'état antérieur : il s'interrompt, les nouveaux pods qui échouent aux sondes ne remplacent pas les anciens, et c'est un opérateur qui déclenche le retour à la version précédente avec kubectl rollout undo. La condition pour que cela fonctionne est que les versions soient compatibles entre elles pendant la transition, ce qui implique une discipline côté contrats d'API et migrations de base de données.

Au-delà des cinq fonctions de base

L'orchestration de Kubernetes ne se limite pas à ces cinq fonctions. En pratique, un cluster Kubernetes en production gère aussi la configuration applicative (ConfigMaps), les secrets (avec ou sans chiffrement au repos), le stockage persistant via les PersistentVolumeClaims, l'autorisation (RBAC), l'isolation réseau (NetworkPolicies), l'observabilité (logs, métriques, traces), et la gestion du cycle de vie des certificats. Chacune de ces fonctions est elle-même une responsabilité opérationnelle qui s'ajoute au socle.

Sans orchestrateur vs avec Kubernetes : comparaison fonction par fonction

Le tableau ne hiérarchise pas les deux colonnes. Il montre que Kubernetes fournit un modèle unifié pour ces cinq fonctions, là où une approche sans orchestrateur les traite séparément avec des outils différents. Pour un système qui n'a pas besoin de cette unification, la colonne de gauche reste pertinente.

Pratiques fréquentes à connaître

Choisir l'outil en fonction du besoin, pas par défaut. Toutes les applications n'ont pas besoin de scheduling, de scaling automatique ou de service discovery au niveau qu'offre Kubernetes. Un PaaS, un déploiement sur VM, ou un binaire systemd répondent à de nombreux besoins avec un autre modèle d'exploitation.

Penser l'observabilité dès le départ. Un cluster Kubernetes sans logs centralisés, sans métriques agrégées et sans traces devient rapidement difficile à exploiter au-delà de quelques services. L'observabilité fait partie intégrante de l'orchestration, pas d'un ajout optionnel.

Définir requests et limits avant d'activer l'autoscaling. Le HPA et le Cluster Autoscaler s'appuient sur les ressources déclarées des pods pour décider du scaling. Sans déclaration, leurs décisions reposent sur des informations partielles.

Soigner la configuration des sondes. Les liveness et readiness probes conditionnent à la fois le self-healing et l'acheminement du trafic. Une configuration approximative dégrade ces deux fonctions simultanément.

Quand l'orchestration Kubernetes devient pertinente

Aucune des cinq fonctions, prise isolément, ne justifie d'introduire Kubernetes dans un système. Un script de déploiement, un load balancer correctement configuré, un outil de monitoring avec restart automatique peuvent couvrir individuellement chacune d'elles. Ce qui justifie l'adoption d'un orchestrateur, c'est le moment où les cinq fonctions deviennent simultanément nécessaires sur une infrastructure suffisamment distribuée pour rendre les solutions ad hoc coûteuses à maintenir.

Concrètement, cela correspond à des architectures avec une dizaine de services ou plus, déployés sur plusieurs machines, avec des cycles de déploiement fréquents, des variations de charge significatives et des exigences de résilience qui ne tolèrent plus l'intervention manuelle. Pour des contextes plus contraints en ressources (edge, IoT, machines de développement, petits clusters), une distribution Kubernetes allégée comme K3s peut convenir. Un PaaS répond également à ces besoins, comme à bien d'autres profils d'applications (déploiement industrialisé, scaling automatique, résilience, mises à jour), avec un modèle d'exploitation distinct de Kubernetes.

Lorsque Kubernetes devient pertinent, la question suivante porte rarement sur l'installation et plus souvent sur l'exploitation au quotidien : mises à jour du control plane, gestion d'etcd, rotation des certificats, observabilité, sauvegardes. C'est ce constat qui explique l'adoption croissante des services Kubernetes managés. Côté Clever Cloud, Clever Kubernetes Engine répond à ce besoin avec Materia etcd, une implémentation serverless de l'API etcd bâtie sur FoundationDB qui prend le relais de l'etcd standard, devenu un goulot d'étranglement à grande échelle, sur une infrastructure souveraine répartie sur nos trois datacenters parisiens.

L'orchestration de conteneurs en synthèse

L'orchestration de conteneurs automatise plusieurs catégories de décisions opérationnelles, dont cinq grandes classes principales : où placer un conteneur, quand en démarrer plus, que faire quand l'un d'eux tombe, comment ils se trouvent entre eux, comment passer d'une version à la suivante sans interruption. Kubernetes regroupe ces fonctions sous un modèle unifié, ce qui en fait l'outil de référence pour les systèmes distribués qui en ont besoin simultanément. La question utile, face à un projet, n'est pas de savoir si on doit faire de l'orchestration, mais lesquelles de ces fonctions sont réellement nécessaires, et à quel niveau d'automatisation.

FAQ - Kubernetes orchestration

Quelle est la différence entre conteneurisation et orchestration ?

La conteneurisation empaquette une application et ses dépendances dans un format standardisé exécutable de manière identique sur n'importe quel hôte compatible. L'orchestration automatise la gestion d'un parc de conteneurs en production : placement, scaling, self-healing, service discovery, mises à jour. Docker est l'outil de référence pour la première, Kubernetes pour la seconde.

Faut-il forcément Kubernetes pour orchestrer des conteneurs ?

Non. Kubernetes est l'orchestrateur le plus largement adopté, mais d'autres existent : Nomad de HashiCorp, qui orchestre conteneurs, VM et binaires dans un même cluster, ou Docker Swarm, toujours maintenu mais dont l'adoption a reculé. Apache Mesos, longtemps cité comme alternative, a été retiré dans l'Apache Attic en octobre 2025 et n'est plus en développement actif. Par ailleurs, un PaaS comme Clever Cloud assure l'ensemble de ces fonctions d'orchestration (placement, scaling automatique, self-healing, rolling updates, service discovery) avec son propre control plane, indépendant de Kubernetes. C'est ce control plane qui orchestre aussi bien les applications exécutées en VM que les conteneurs du runtime Docker de la plateforme.

L'orchestration de conteneurs est-elle nécessaire pour CI/CD ?

Non, mais elle est souvent utilisée conjointement. Les pipelines CI/CD modernes produisent des images de conteneurs comme artefact final, et l'orchestrateur (Kubernetes ou autre) prend le relais pour déployer et exploiter ces images. CI/CD et orchestration sont deux étapes complémentaires du cycle de vie applicatif.

K3s permet-il l'orchestration en environnement contraint ?

Oui. K3s est une distribution Kubernetes certifiée CNCF, conçue pour les environnements aux ressources limitées (edge, IoT, machines de développement, petits clusters). Elle conserve les API standards de Kubernetes tout en réduisant l'empreinte ressources et la complexité de déploiement.

Un Kubernetes managé change-t-il les fonctions d'orchestration disponibles ?

Non. Un Kubernetes managé fournit le même ensemble de fonctions d'orchestration qu'un cluster auto-hébergé, puisqu'il s'agit du même Kubernetes. La différence porte sur la répartition des responsabilités opérationnelles : le fournisseur prend en charge la gestion du control plane, les mises à jour, la supervision sous-jacente. Les utilisateurs se concentrent alors sur leurs workloads applicatifs.

Quelle est la fonction d'orchestration la plus difficile à maîtriser ?

Le réseau est fréquemment cité comme la plus complexe. Service discovery, load balancing interne, NetworkPolicies, Ingress, plugin CNI, observabilité du trafic est-ouest : la couche réseau de Kubernetes concentre une part significative des sujets opérationnels avancés et reste une source fréquente d'incidents en production.

Cela représente une étape importante, issue de trois années de préparation, et s’inscrit dans une stratégie plus large visant à conserver un contrôle complet sur l’infrastructure réseau de notre région Paris.

Pourquoi ce changement

Aux débuts de Clever Cloud, nous avons délégué la gestion du réseau à des partenaires. Ce choix était logique : il nous permettait d’accélérer le développement, de nous concentrer sur les services cloud, et d’éviter d’investir immédiatement dans une expertise que nous ne maîtrisions pas encore.

Mais à mesure que notre infrastructure a grandi, les limites de cette dépendance sont devenues évidentes. Nous n’avions aucun contrôle sur des décisions stratégiques : la manière dont le trafic était routé sur Internet, les chemins empruntés par nos paquets, ou la rapidité avec laquelle nous pouvions réagir aux incidents. Chaque modification, chaque incident nécessitait l’intervention d’un tiers.

Nous avons donc décidé de reprendre cette responsabilité. Cela nous a permis d’obtenir plusieurs avantages concrets. Nous optimisons les coûts grâce à la gestion directe de nos relations de transit et de peering. Nous définissons notre propre politique de routage au lieu de subir les contraintes d’un intermédiaire. Nous résolvons les incidents nous-mêmes, sans dépendre de fournisseurs externes. Et nous obtenons un contrôle complet de notre stack réseau — dans la continuité du contrôle que nous avons progressivement acquis sur nos serveurs et nos datacenters au cours des dernières années.

Mais cette transition ne concerne pas uniquement notre indépendance opérationnelle. Elle apporte des bénéfices immédiats et concrets pour nos utilisateurs. Le plus important est la résilience. Auparavant, l’ensemble du trafic passait par un seul fournisseur. Tout incident de leur côté impactait l’ensemble des services. Nous disposons désormais de quatre fournisseurs upstream répartis sur trois datacenters en région parisienne. Lorsqu’un lien tombe — ce qui s’est produit au cours de l’année passée — le trafic bascule automatiquement vers les alternatives disponibles, sans interruption pour les utilisateurs. Nous pouvons même absorber la perte simultanée de plusieurs liens de transit.

Au-delà de la redondance, nous gagnons le contrôle du routage lui-même. Nous décidons désormais comment le trafic atteint sa destination. Cela nous permet d’optimiser les chemins pour réduire la latence et améliorer les performances, et d’ajuster ces décisions en fonction des besoins spécifiques et de la topologie réseau. Nous réagissons en temps réel à la congestion, aux variations du réseau et aux contraintes opérationnelles.

Enfin, la responsabilité opérationnelle change. Les incidents réseau ne nécessitent plus d’attendre qu’un fournisseur externe les prenne en charge. Les défaillances du réseau public relèvent directement de notre responsabilité : nous les détectons, les analysons et les corrigeons. Cela réduit directement le temps entre l’apparition d’un problème et sa résolution, ce qui améliore la disponibilité et la fiabilité pour nos utilisateurs.

Exploiter son propre réseau sur Internet

Pour opérer un réseau indépendant sur Internet, une organisation doit travailler avec un registre Internet régional (RIR). Les RIR sont responsables de l’attribution et de la gestion des adresses IP et des numéros d’AS dans des zones géographiques spécifiques.

Il existe cinq RIR dans le monde :

• RIPE NCC — Europe, Asie centrale et Moyen-Orient
• ARIN — Amérique du Nord (États-Unis, Canada, Caraïbes)
• LACNIC — Amérique latine et Caraïbes
• APNIC — région Asie-Pacifique
• AFRINIC — Afrique

Pour Clever Cloud, dont l’infrastructure est principalement en Europe, nous travaillons avec le RIPE NCC (Réseaux IP Européens).

Espace d’adressage alloué

En tant que membre d’un RIR, une organisation reçoit des allocations d’adresses IPv4 et IPv6. Pour les membres du RIPE NCC, cela correspond généralement à un bloc IPv4 en /24 (selon disponibilité) et un bloc IPv6 en /29. Ces ressources sont associées à l’organisation et peuvent être utilisées pour opérer un réseau à l’échelle globale.

Création de notre système autonome

Les bases de cette transition ont été posées plusieurs années auparavant. En 2019, nous avons créé notre compte RIPE NCC afin de devenir LIR (Local Internet Registry). Cela nous a permis d’obtenir un bloc IPv4 /24 (91.208.207.0/24) et un bloc IPv6 /29 (2a0f:d0c0::/29).

Puis, en 2022, nous avons enregistré notre numéro de système autonome (ASN) auprès du registre régional. Notre numéro d’AS est AS213394.

> whois AS213394

aut-num:        AS213394
as-name:        CleverCloud
org:            ORG-CCS42-RIPE
import:         from AS29075 accept ANY
import:         from AS3257 accept ANY
import:         from AS3356 accept ANY
import:         from AS43424 accept ANY
export:         to AS29075 announce AS213394:AS-CLVRCLD
export:         to AS3257 announce AS213394:AS-CLVRCLD
export:         to AS3356 announce AS213394:AS-CLVRCLD
export:         to AS43424 announce AS213394:AS-CLVRCLD
admin-c:        QA171-RIPE
tech-c:         QA171-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         mnt-fr-clvrcldnet-1
created:        2022-11-28T08:24:23Z
last-modified:  2025-02-25T16:36:15Z
source:         RIPE

Un ASN (Autonomous System Number) est un identifiant unique attribué à un réseau sur Internet. Il est nécessaire pour annoncer des routes via BGP, le protocole qui permet le routage entre réseaux.

Maintenant que nous disposons d’un ASN, nous pouvons annoncer nos préfixes aux autres réseaux via le protocole BGP.

Le rôle de la base de données RIPE

Le RIPE NCC maintient une base de données publique d’objets de routage (comme l’objet aut-num présenté précédemment). Parmi ces objets figurent les objets de type route, qui indiquent quel système autonome (AS) est autorisé à annoncer un préfixe IP donné.

En pratique, ces entrées sont principalement utilisées par les opérateurs réseau et les fournisseurs de transit pour construire leurs politiques de routage et leurs mécanismes de filtrage (filtrage basé sur l’IRR). Ces filtres permettent d’accepter ou de rejeter les annonces reçues de leurs pairs. Il s’agit d’un des mécanismes utilisés pour tenter de prévenir les détournements BGP (BGP hijacks).

En appliquant ces filtres aux routes reçues de leurs pairs, les opérateurs peuvent limiter la propagation d’un préfixe annoncé par un ASN non autorisé.

Prenons un exemple : imaginons que l’organisation A possède le préfixe 192.0.2.0/24 et l’annonce à un fournisseur de transit X. Le fournisseur X applique un filtre sur les routes reçues de l’organisation A afin de n’accepter que les préfixes IP enregistrés dans la base RIR de cette organisation.

Dans ce cas, si l’organisation A commence à annoncer un préfixe qui ne lui appartient pas (par exemple notre préfixe public 91.208.207.0/24), le fournisseur X est censé rejeter cette annonce. Cela permet d’éviter qu’une route incorrecte soit propagée sur Internet et que le trafic soit redirigé vers une entité non légitime.

Le protocole BGP : comment Internet route le trafic

Pour comprendre comment nous annonçons nos préfixes sur Internet, il est essentiel de comprendre BGP — le Border Gateway Protocol. BGP est le protocole de routage de référence sur Internet. Il permet aux réseaux (systèmes autonomes) d’échanger des informations sur les préfixes IP qu’ils possèdent et sur la manière de les atteindre.

BGP fonctionne dans les deux sens. Lorsque nous annonçons à nos pairs et à nos fournisseurs de transit « nous possédons 91.208.207.0/24 », cette annonce se propage sur Internet de réseau en réseau. Chaque réseau qui relaie cette annonce ajoute son propre numéro d’AS dans le AS_PATH — une liste qui représente la séquence de réseaux qu’un paquet doit traverser pour nous atteindre.

Par exemple, OVHcloud (AS16276) voit le chemin [AS29075, AS213394] : le trafic passe par l’un de nos fournisseurs de transit (AS29075), puis arrive jusqu’à nous (AS213394). Chaque réseau qui relaie l’annonce la met à jour de cette manière, construisant progressivement un chemin complet.

Voici un exemple obtenu via le service Looking Glass d’OVHcloud :

> show route for 91.208.207.0/24 all

91.208.207.0/24    via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
    Type: BGP unicast univ
    BGP.origin: IGP
    BGP.as_path: 29075 213394
    BGP.next_hop: 172.18.16.0
    BGP.med: 161
    BGP.local_pref: 40
    BGP.community: (0,0) (29075,18000) (65535,65281)
    BGP.23 [t]: 00 00 b8 6e
                   via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]

Dans le même temps, nous recevons des annonces provenant d’autres réseaux concernant leurs propres préfixes et les chemins permettant de les atteindre. Cela construit la vue inverse : lorsque nous devons envoyer du trafic sortant, nous savons quel chemin emprunter pour atteindre une destination donnée.

Voici un exemple avec un préfixe d’OVHcloud :

> /routing/route/print detail where dst-address=5.39.0.0/17 and active

Ab   afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"

      bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igp

Dans cet exemple, le chemin réseau utilisé par OVHcloud pour nous atteindre est différent de celui que nous utilisons pour les atteindre.

Le processus de migration

os préfixes IP étaient entièrement gérés par notre fournisseur historique. Bien que nous en soyons propriétaires, nous lui avions délégué leur annonce sur Internet.

Cela impliquait que son ASN (AS43424) apparaissait comme origine dans les tables de routage, et que l’ensemble du trafic transitait par son infrastructure.

Clever Cloud Services
   |
   | all inbound/outbound traffic
   v
Historical Provider (AS43424)
   |
   | originates: 91.208.207.0/24 (origin AS43424)
   v
Internet

Nous voulions que notre ASN devienne l’origine des annonces. Pour cela, nous avons planifié une migration en trois étapes, sans interruption pour les utilisateurs.

Migration d’un préfixe entre AS

Pour migrer un préfixe d’un AS vers un autre, nous devions modifier son objet route dans la base de données RIPE. La procédure était relativement simple, mais nécessitait un timing précis.

Nous avons d’abord créé un second objet route dans la base RIPE pour notre préfixe 91.208.207.0/24. Désormais, les deux ASN étaient enregistrés comme autorisés à annoncer ce même préfixe — à la fois l’AS de notre fournisseur historique et notre propre AS (213394).

Ces objets de routage sont interrogeables publiquement via la commande whois ou via l’interface web du RIPE. Par exemple, la commande suivante permet d’obtenir les deux objets enregistrés :

❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
descr:          CleverCloud subnet
origin:         AS213394
created:        2025-01-15T10:29:14Z
last-modified:  2025-01-15T10:29:14Z
source:         RIPE

% Information related to '91.208.207.0/24AS43424'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
mnt-by:         MAGICRETAIL-MNT
descr:          CleverCloud subnet
origin:         AS43424
created:        2020-02-13T09:06:33Z
last-modified:  2020-02-13T09:06:48Z
source:         RIPE

Une fois ce second objet route enregistré et propagé sur Internet (c’est-à-dire une fois que les opérateurs réseau ont récupéré une version à jour de la base RIPE pour construire leurs filtres de routage), nos nouveaux fournisseurs de transit pouvaient constater que notre ASN était autorisé à annoncer ce préfixe. À partir de ce moment-là, nous pouvions commencer à annoncer ce préfixe via notre propre infrastructure.

Si nous n’avions pas créé cet objet route, nos annonces auraient pu être rejetées et nous aurions pu être considérés comme des acteurs malveillants réalisant un détournement BGP (BGP hijack).

Annonce via notre fournisseur historique

Une fois le second objet route propagé, nous avons réalisé la première étape dans la nuit du 16 janvier 2025 : nous avons commencé à annoncer nous-mêmes le préfixe via BGP à notre fournisseur historique.

Le trafic continuait d’emprunter le même chemin de transit, mais cette fois avec Clever Cloud (AS213394) comme origine des annonces, au lieu de notre fournisseur historique. Ce dernier continuait à relayer le préfixe, mais le recevait désormais de notre part au lieu de l’annoncer directement.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   v
Historical Provider (AS43424)
   |
   | re-announces: 91.208.207.0/24 (origin AS213394)
   v
Internet

Cette première phase a servi de validation : en cas de problème, nous pouvions revenir rapidement en arrière sans impacter les autres chemins de transit.

Annonce via nos propres transits

Quelques jours plus tard, dans la nuit du 21 janvier 2025, nous avons franchi l’étape finale : nous avons commencé à annoncer le préfixe via nos propres connexions de transit dédiées.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   |
   +---+---+---+
   |   |   |   |
   v   v   v   v
  T1  T2  T3  HP
(Transit providers + historical provider)
   |   |   |   |
   +---+---+---+
   |
   v
Internet

Nous annonçons désormais nos préfixes directement à quatre fournisseurs upstream (trois fournisseurs de transit, T1/T2/T3, ainsi que notre fournisseur historique HP). Le trafic circule à travers l’ensemble de ces chemins, et nous disposons d’un contrôle complet sur les décisions de routage ainsi que sur la redondance.

Tout au long de ces deux phases, nous n’avons observé aucune interruption ayant un impact pour les utilisateurs. La redondance intrinsèque du protocole BGP, combinée à la nature progressive de la transition, a permis d’assurer un écoulement du trafic sans interruption, quel que soit le chemin privilégié à un instant donné.

Visibilité complète du routage Internet

Dans le cadre de la phase 2, nos trois principaux fournisseurs de transit ont commencé à nous fournir une « full view » de la table de routage Internet. Il s’agit de l’ensemble complet des préfixes IPv4 et IPv6 publiquement annoncés — soit environ 1 million de routes IPv4 et 220 000 routes IPv6.

Disposer d’une full view nous offre une visibilité inédite sur la structure d’Internet et nous permet de prendre des décisions de routage avancées. Au lieu de dépendre de la vision d’un seul fournisseur, nous avons désormais accès à l’ensemble des chemins disponibles pour atteindre n’importe quelle destination.

Avec ces informations, nous sommes en mesure de choisir les chemins optimaux pour notre trafic sortant en fonction de notre topologie réseau et de nos préférences, de mettre en œuvre du traffic engineering pour diriger les flux via des fournisseurs de transit spécifiques, de réagir dynamiquement aux conditions réseau et à la congestion, et d’équilibrer la charge entre nos quatre connexions de transit en nous appuyant sur des données de routage en temps réel.

Ce niveau de contrôle fin sur notre politique de routage est une conséquence directe de l’exploitation de notre propre système autonome et de la gestion de nos propres annonces — exactement le niveau d’indépendance opérationnelle que nous recherchions au début de cette transition.

Un an plus tard

Près d’un an après le début de l’exploitation de nos propres annonces réseau, la transition s’est révélée concluante. Nous n’avons rencontré aucun incident majeur et notre infrastructure a démontré sa résilience. Lorsque des incidents mineurs se sont produits — comme des pertes de paquets sur un fournisseur de transit spécifique ou la perte temporaire d’un lien — le trafic s’est automatiquement rééquilibré sur les connexions restantes.

Nous avons pu détecter et corriger ces problèmes directement, sans dépendre d’un fournisseur tiers. Nos utilisateurs n’ont subi aucune interruption ayant un impact. Cette capacité à assumer la responsabilité de notre réseau et à résoudre rapidement les problèmes est sans doute le principal bénéfice de cette transition.

Et ensuite

Cette transition est loin d’être terminée. Plusieurs évolutions sont prévues :

• augmentation de la capacité réseau pour absorber la croissance du trafic
• mise en place de peering BGP avec d’autres réseaux pour optimiser le trafic local sans recourir au transit
• déploiement de ROA (Route Origin Authorization) pour signer cryptographiquement nos annonces et prévenir les détournements de préfixes
• validation RPKI (Resource Public Key Infrastructure) pour vérifier la légitimité des annonces reçues et renforcer la sécurité du routage
• extension d’IPv6, en entrée (réception de trafic IPv6) comme en sortie (émission de trafic IPv6), déployée progressivement

Conclusion

Début 2025, Clever Cloud a finalisé sa transition vers une exploitation entièrement autonome de son réseau. Nous annonçons désormais nos propres préfixes IP via quatre fournisseurs upstream, ce qui nous donne un contrôle complet sur la manière dont le trafic entre et sort de notre infrastructure.

Pour nos utilisateurs, cela se traduit par une meilleure fiabilité et des temps de résolution plus courts dans notre région Paris. Lorsqu’un incident réseau survient, nous le traitons directement, et notre redondance multi-fournisseurs garantit la continuité du trafic.

Cette étape marque le début d’une nouvelle phase. Nous travaillons déjà sur le peering BGP pour optimiser le trafic local, sur le déploiement de ROA et la validation RPKI pour renforcer la sécurité du routage, ainsi que sur l’extension d’IPv6 pour généraliser le dual-stack. Nous construisons un réseau aussi robuste et autonome que le reste de notre infrastructure.

L’Identity and Access Management (IAM) est devenu un composant central de toute architecture moderne. Authentification, gestion des utilisateurs, contrôle des accès, conformité réglementaire : ces briques sont critiques, mais leur mise en œuvre et leur exploitation restent souvent complexes dans la durée.

C’est pour répondre à ces enjeux que Clever Cloud a lancé l'IAM Keycloak as a Service au printemps 2025, en partenariat avec Please Open It, société spécialisée dans l’intégration et l’expertise autour de Keycloak. Cette collaboration a permis de concevoir un service managé, aligné à la fois sur les bonnes pratiques de l’open source et sur les contraintes réelles des environnements de production.

Depuis son lancement, Keycloak as a Service a connu de nombreuses évolutions pour répondre aux usages concrets des entreprises et aux exigences d’un IAM opéré à grande échelle.

Un Keycloak managé, pensé pour la production

Keycloak as a Service repose sur une approche simple : offrir toute la richesse fonctionnelle de Keycloak, sans demander aux équipes de gérer l’infrastructure, la maintenance ou la supervision.

Le service est intégré nativement à la Console Clever Cloud. Il devient ainsi une brique à part entière de la plateforme, pilotable depuis un point unique, au même titre que les autres services managés.

Secured Multi Instances : haute disponibilité et montée en charge

Parmi les évolutions majeures figure le Secured Multi Instances. Il permet de déployer Keycloak en mode clusterisé, avec plusieurs nœuds, afin d’assurer la répartition de charge et la haute disponibilité d’un composant critique comme l’IAM.

Cette architecture renforce la continuité de service et la capacité à absorber la montée en charge, tout en répondant aux exigences attendues en production. La configuration et le pilotage de cette architecture sont accessibles directement depuis la Console Clever Cloud.

Un dashboard dédié dans la Console

Un dashboard Keycloak est désormais disponible dans la Console Clever Cloud. Il centralise les informations essentielles du service ainsi que les actions d’administration courantes, afin de simplifier le pilotage au quotidien et d’éviter la multiplication des outils.

Monitoring intégré et inclus

Le monitoring est intégré nativement au service. La visibilité opérationnelle est immédiatement disponible, sans configuration supplémentaire ni déploiement d’outils externes.

Cette approche intégrée permet de simplifier l’exploitation tout en conservant un haut niveau de maîtrise sur le fonctionnement de l’IAM.

Maintenance continue et mises à jour

Keycloak managé est maintenu à jour par les équipes Clever Cloud. Les versions récentes de Keycloak sont mises à disposition au fil des évolutions du produit, sans charge opérationnelle côté client.

Cela permet de bénéficier des correctifs de sécurité et des évolutions fonctionnelles, sans projets de montée de version lourds ou risqués.

L’ajout simplifié à vos applications

Enfin, une évolution plus structurelle concerne Request Flow, un socle technique qui facilite l’utilisation d’outils afin de protéger l’accès à vos applications, dont OAuth2-Proxy. 

Ce dernier est compatible avec Keycloak, sa configuration est simplifiée sur Clever Cloud, ce qui permet de mettre en place une identification en amont de l’application, sans modification du code applicatif. Il est particulièrement adapté pour sécuriser des applications existantes, des back-offices, des outils internes ou des services exposés.

Pour aller plus loin

Pour présenter ces évolutions en détail, partager les choix techniques et répondre aux questions, un live Twitch et Youtube est prévu le 26 février à 13h. Il sera animé par Horacio Gonzalez (Clever Cloud), avec Mathieu Passenaud (Please Open It). L’occasion d’entrer concrètement dans le fonctionnement de notre Keycloak managé et d’échanger autour des usages IAM en production.

C’est dans ce contexte que la stack ELK s’est imposée comme un socle technique pour analyser, rechercher et visualiser des données techniques, en particulier les logs. Dans cet article, nous répondons à trois questions essentielles :

• ELK Stack, c’est quoi exactement ?
• À quoi ça sert aujourd’hui, notamment pour l’observabilité ?
• Comment l’utiliser efficacement sans gérer toute l’infrastructure ?

ELK Stack : définition claire

ELK Stack est un acronyme qui désigne historiquement trois composants :

• Elasticsearch : moteur distribué de recherche et d’analyse ;
• Kibana : interface de visualisation et d’exploration des données ;
• Logstash : outil de collecte et de transformation de données (selon les contextes).

À l’heure actuelle, Elasticsearch et Kibana constituent le cœur fonctionnel de la stack ELK, en particulier pour les usages d’analyse et de visualisation des données techniques, une fois les données ingérées dans Elasticsearch.

On parle parfois d’Elastic Stack, un terme plus large qui englobe l’écosystème Elastic dans son ensemble. Dans l’usage courant, notamment en environnement cloud, l’ELK Stack désigne l’association d’un mécanisme de collecte, souvent basé sur des agents, avec Elasticsearch pour le stockage et l’analyse, et Kibana pour la visualisation.

À quoi sert ELK Stack ?

ELK Stack sert à centraliser, analyser et exploiter des données techniques issues de systèmes et d’applications. Elle permet d’indexer de grands volumes de données, d’effectuer des recherches et des analyses sur de larges plages temporelles, en croisant des données issues de multiples sources, services ou environnements.

Cette capacité d’analyse en fait un outil largement utilisé pour comprendre le comportement d’une application, diagnostiquer des incidents, investiguer des anomalies ou explorer des données opérationnelles. L’intérêt principal réside dans la possibilité de passer rapidement de données brutes à des informations exploitables, sans dépendre d’outils spécialisés pour chaque cas d’usage.

ELK Stack et observabilité : quel lien ?

L’observabilité vise à comprendre l’état interne d’un système à partir de ses signaux observables. Parmi ces signaux, les logs jouent un rôle central, car ils décrivent précisément ce que fait une application à un instant donné.

Dans ce cadre, ELK Stack constitue un socle particulièrement adapté à l’observabilité orientée logs. Elasticsearch permet de rechercher et de corréler des événements à grande échelle, tandis que Kibana offre une lecture visuelle qui facilite l’analyse et l’interprétation. L’ensemble permet d’identifier des comportements anormaux, de reconstituer la chronologie d’un incident ou d’analyser des tendances sur la durée.

Comment utiliser ELK Stack sans gérer l’infrastructure

L’un des principaux freins à l’adoption d’ELK Stack a longtemps été sa complexité opérationnelle. Déployer, maintenir et faire évoluer une telle stack implique de gérer le dimensionnement, les mises à jour, la sécurité ou encore les sauvegardes.

En environnement cloud, cette charge peut rapidement détourner les équipes de leur objectif principal, qui est l’analyse des données et non la gestion de l’infrastructure. C’est pour cette raison que de plus en plus d’équipes se tournent vers des approches managées.

Approche managée

Dans une approche managée, Elasticsearch et Kibana sont fournis sous forme de services prêts à l’emploi. L’infrastructure sous-jacente et une partie des opérations courantes (mise à disposition du service, maintenance, sauvegardes, contrôle d’accès selon le modèle de la plateforme) sont pris en charge par la plateforme, ce qui permet aux équipes de se concentrer sur les usages.

Dans ce modèle, la collecte des logs est assurée par les mécanismes de la plateforme. Sur Clever Cloud, les applications et add-ons peuvent exposer leurs logs via des drains, qui permettent de les rediriger vers un Elasticsearch cible, sans déployer d’outil de collecte dans le PaaS.

Sur Clever Cloud, il est par exemple possible de créer un add-on Elastic Stack qui fournit :

• un service Elasticsearch managé ;
• une instance Kibana associée ;
• des mécanismes de sécurité et de sauvegarde intégrés ;
• une connexion via les informations d’accès fournies par l’add-on.

Cette approche permet d’exploiter ELK Stack sans gérer les aspects bas niveau, tout en conservant la puissance d’analyse d’Elasticsearch.

Cas d’usage concrets en observabilité

Analyse de logs applicatifs

Centraliser les logs applicatifs dans Elasticsearch permet de rechercher rapidement des erreurs, d’explorer des événements précis ou de filtrer des données selon différents critères. Cette capacité est essentielle pour comprendre le comportement réel d’une application en production.

Diagnostic d’incidents

Lorsqu’un incident survient, la corrélation des événements devient un enjeu clé. ELK Stack permet d’analyser la chronologie des faits, d’identifier les composants impliqués et de mieux comprendre les causes sous-jacentes, sans se limiter à une vision fragmentée des logs.

Suivi du comportement applicatif

Sur la durée, l’analyse des données indexées dans Elasticsearch permet de détecter des tendances, des pics anormaux ou des évolutions de comportement. Les tableaux de bord Kibana facilitent cette lecture et offrent une vision synthétique adaptée aux équipes techniques.

Conclusion

ELK Stack reste aujourd’hui un socle solide pour analyser et exploiter des données techniques, en particulier les logs. Son rôle dans les démarches d’observabilité s’est renforcé avec l’évolution des architectures cloud et distribuées.

En s’appuyant sur le cœur fonctionnel de la stack ELK, à savoir Elasticsearch et Kibana, il est possible de construire un environnement d’analyse adapté aux besoins modernes, sans nécessairement gérer l’infrastructure sous-jacente. Les approches managées permettent de réduire la complexité opérationnelle et de se concentrer sur la valeur des données.

Les usages autour de l’ELK Stack continuent toutefois d’évoluer. Les travaux récents d’Elastic autour de nouveaux modèles de gestion des logs, comme les streams, ouvrent la voie à des approches plus flexibles et mieux adaptées aux volumes actuels. Ces évolutions prolongent les fondations existantes, sans remettre en cause le rôle central d’Elasticsearch dans l’analyse des données d’observabilité.

Pour celles et ceux qui souhaitent explorer ces usages dans un cadre maîtrisé, créer un add-on Elastic Stack sur Clever Cloud constitue une manière pragmatique d’aborder l’observabilité basée sur Elasticsearch, sans transformer l’exploitation en contrainte.

C’est précisément le rôle de l’observabilité. Et c’est aussi la raison pour laquelle Elasticsearch s’est progressivement imposé comme un socle d’analyse pour les logs, les métriques et les traces.

Nous allons voir comment Elasticsearch s’inscrit dans une démarche d’observabilité, au-delà du simple logging, et comment il permet de corréler les signaux techniques pour mieux comprendre le comportement des applications.

Qu’est-ce que l’observabilité, et pourquoi Elasticsearch est concerné

L’observabilité désigne la capacité à comprendre l’état interne d’un système à partir de ses signaux externes. Contrairement au monitoring traditionnel, elle ne se limite pas à des métriques prédéfinies ou à des seuils fixes.

Elle repose sur la collecte de données riches et contextuelles, sur leur analyse transversale et sur la possibilité d’explorer des situations non anticipées. Dans ce cadre, Elasticsearch joue un rôle clé. Son moteur d’indexation et de recherche permet d’analyser de grands volumes de données hétérogènes, structurées ou non, en quasi temps réel, ce qui correspond exactement aux besoins d’une approche d’observabilité moderne.

Les trois piliers de l’observabilité : logs, métriques et traces

Une stratégie d’observabilité repose sur trois types de signaux complémentaires. Chacun répond à une problématique différente.

Logs : comprendre ce qui s’est passé

Les logs sont des événements produits par les applications et les composants d’infrastructure. Dans Elasticsearch, ils sont associés à un horodatage, qu’il provienne du contenu du log lui-même ou du moment de son ingestion. Ils fournissent un niveau de détail élevé et permettent de comprendre le contexte précis d’une erreur, d’un comportement inattendu ou d’un incident.

Elasticsearch est historiquement très adapté à cet usage :

• ingestion de volumes importants ;
• recherche plein texte rapide ;
• exploration fine des événements.

Les logs apportent beaucoup de contexte, mais deviennent difficiles à exploiter seuls lorsque les architectures se distribuent et que les volumes augmentent fortement.

Métriques : mesurer l’état du système

Les métriques sont des données numériques agrégées dans le temps. Elles décrivent l’état global d’un système et permettent de suivre son évolution. Latence, taux d’erreur ou consommation de ressources donnent une vision synthétique de la santé d’une application ou d’une infrastructure.

Dans Elasticsearch, ces données sont stockées sous forme de séries temporelles. Cela permet de réaliser des agrégations, d’analyser des tendances sur la durée et de détecter des anomalies, tout en conservant la possibilité de relier ces métriques à d’autres signaux techniques.

Traces : suivre une requête de bout en bout

Les traces décrivent le parcours complet d’une requête à travers un système distribué. Elles sont essentielles pour comprendre les dépendances entre services et identifier précisément l’origine d’une latence ou d’une erreur.

Chaque trace est composée de plusieurs segments représentant les différentes étapes d’exécution. Une fois indexées dans Elasticsearch, ces traces peuvent être reliées aux logs et aux métriques associées, ce qui facilite l’analyse des comportements complexes dans des environnements microservices.

Comment Elasticsearch corrèle logs, métriques et traces

La valeur de l’observabilité ne réside pas dans chaque signal pris isolément, mais dans leur corrélation. Elasticsearch la facilite grâce à plusieurs mécanismes structurants :

• un moteur d’indexation commun ;
• des schémas partagés comme ECS (Elastic Common Schema), qui fournit une structure commune pour les logs, les métriques et les traces ;
• des capacités de recherche transverses.

Concrètement, cette approche permet de naviguer naturellement entre les signaux. Une alerte issue d’une métrique peut conduire à l’analyse des traces concernées, puis à l’exploration des logs associés à une requête précise. Kibana joue ici un rôle central en rendant ces corrélations visibles et exploitables, grâce à des visualisations, des tableaux de bord et des outils d’exploration adaptés à l’analyse croisée des signaux.

Historiquement, Elasticsearch est surtout connu pour permettre de créer des moteurs de recherche applicatifs, notamment pour indexer et interroger des contenus sur des sites web. Ce même principe de recherche rapide et contextuelle s’applique aux données d’observabilité : logs, métriques et traces sont eux aussi indexés et interrogés comme des ensembles de données, ce qui rend possible leur exploration et leur corrélation à grande échelle.

OpenTelemetry : un standard clé pour l’observabilité avec Elasticsearch

Dans les architectures modernes, la collecte des données est un enjeu aussi important que leur analyse. OpenTelemetry s’est imposé comme un standard ouvert pour l’instrumentation des applications, couvrant à la fois les traces, les métriques et les logs.

Elasticsearch supporte nativement OpenTelemetry, ce qui permet de standardiser la collecte des signaux sans dépendre d’un format propriétaire. Cette compatibilité facilite l’interopérabilité, limite le verrouillage technologique et permet de faire évoluer les outils d’observabilité sans remettre en cause l’instrumentation applicative existante.

Observer ses applications avec Elastic sur Clever Cloud

Sur Clever Cloud, Elasticsearch est proposé sous forme d’add-on managé. Les applications peuvent y envoyer leurs logs via des drains Elasticsearch, ce qui permet de centraliser automatiquement les logs applicatifs. Plusieurs briques peuvent ensuite être activées selon les besoins :

• un Elasticsearch administré ;
• Kibana pour l’exploration et la visualisation ;
• Elastic APM pour l’analyse des performances applicatives.

Cette approche permet de centraliser les logs applicatifs, de collecter des métriques pertinentes et de tracer les requêtes sans avoir à gérer l’infrastructure sous-jacente. L’objectif n’est pas de multiplier les outils, mais de fournir une base d’observabilité cohérente, intégrée au cycle de vie des applications.

Conclusion

L’observabilité ne se résume pas à empiler des outils de monitoring. Elle repose sur la capacité à corréler logs, métriques et traces pour comprendre des systèmes de plus en plus complexes.

Grâce à ses capacités d’indexation, de recherche et d’analyse, Elasticsearch constitue un socle technique solide pour cette approche. Associé à des standards ouverts et à des interfaces comme Kibana, il permet de passer d’une vision fragmentée à une compréhension globale du comportement applicatif.

Dans un environnement cloud moderne, cette corrélation n’est plus un luxe. C’est une condition nécessaire pour exploiter la production de manière fiable.

L’Identity Access Management, ou IAM, est aujourd’hui l’un des fondements de la sécurité et de la gouvernance des systèmes d’information. Derrière ce terme se joue une réalité très concrète : la capacité d’une organisation à contrôler précisément qui accède à quoi, à quel moment, et dans quelles conditions.

Chez Clever Cloud, ces problématiques sont abordées depuis un angle résolument opérationnel. En tant que fournisseur européen de services cloud managés, Clever Cloud accompagne depuis plus de dix ans des organisations publiques et privées confrontées à des enjeux forts de sécurité, de conformité, de maîtrise des coûts et de gestion des compétences. L’offre Keycloak as a Service s’inscrit directement dans cette expérience de terrain.

Identity Access Management : une réalité opérationnelle avant d’être un concept

Un système d’Identity Access Management ne se limite pas à l’authentification des utilisateurs. Il structure l’ensemble des accès aux applications, aux API et aux données.

Concrètement, un IAM efficace permet de :

• identifier de manière fiable les utilisateurs et les services ;
• appliquer des règles d’accès cohérentes et auditables ;
• centraliser l’authentification et les autorisations ;
• tracer les accès pour répondre aux exigences de sécurité et de conformité.

Dans les environnements modernes, où coexistent applications internes, services cloud, partenaires et clients, l’IAM devient rapidement un point de passage obligé. Toute faiblesse à ce niveau a des conséquences immédiates, tant sur la sécurité que sur la continuité de service.

Sécurité, conformité, coûts : pourquoi l’IAM est devenu stratégique

Les retours d’expérience sont clairs : une part significative des incidents de sécurité trouve son origine dans des problèmes d’identités ou de droits mal configurés. Comptes dormants, permissions excessives, absence de traçabilité : autant de situations courantes lorsque la gestion des accès est dispersée.

Sur le plan réglementaire, les organisations doivent démontrer leur capacité à contrôler et à justifier les accès aux données. RGPD, NIS2 ou encore les futures obligations liées à l’IA imposent une gouvernance rigoureuse des identités.

À cela s’ajoutent des enjeux très concrets de gestion des compétences et de budget. Exploiter une solution IAM en interne suppose des équipes formées, disponibles et capables de suivre l’évolution rapide des standards de sécurité. À l’inverse, certaines offres propriétaires peuvent entraîner une dépendance forte et des modèles tarifaires difficiles à anticiper.

L’IAM est donc devenu un sujet de direction, autant qu’un sujet technique.

Keycloak : un standard open source éprouvé

Keycloak s’est imposé comme l’une des solutions open source de référence en matière d’Identity Access Management. Utilisé à grande échelle par des entreprises, des administrations et des éditeurs de logiciels, il repose sur des standards ouverts largement adoptés.

Keycloak couvre notamment :

• le Single Sign-On (SSO) ;
• la fédération d’identités avec des annuaires existants ou des fournisseurs externes ;
• l’authentification multi-facteurs ;
• la gestion fine des rôles et des permissions ;
• l’intégration native avec OAuth2, OpenID Connect et SAML.

Son caractère open source permet une transparence complète sur les mécanismes de sécurité et évite l’enfermement technologique. C’est un point déterminant pour les organisations qui souhaitent garder la maîtrise de leur IAM sur le long terme.

Les limites d’un Keycloak auto‑hébergé

Dans la pratique, déployer Keycloak n’est qu’une première étape. Son exploitation dans des conditions professionnelles pose rapidement des questions de fond :

• haute disponibilité et résilience ;
• mises à jour régulières et correctifs de sécurité ;
• sauvegardes et restauration ;
• supervision et gestion des incidents ;
• sécurisation de l’infrastructure sous-jacente.

Ces sujets mobilisent des compétences spécifiques et du temps opérationnel. Pour de nombreuses équipes, ils deviennent un frein, voire un risque.

Keycloak as a Service par Clever Cloud : l’expertise mise au service de l’IAM

Avec Keycloak as a Service, Clever Cloud propose une approche issue de son expérience d’opérateur cloud managé. La solution repose sur Keycloak, sans modification propriétaire, et bénéficie d’un environnement d’hébergement conçu pour des usages critiques.

Clever Cloud assure l’ensemble des aspects opérationnels : hébergement, mises à jour, supervision, sauvegardes et disponibilité. Les équipes clientes gardent la main sur la configuration fonctionnelle, les règles d’accès et les intégrations applicatives.

Cette répartition claire des responsabilités permet de sécuriser les usages tout en maîtrisant les coûts et les compétences mobilisées.

Hébergement européen et confiance numérique

Les données d’identités font partie des données les plus sensibles d’un système d’information. Leur hébergement et leur traitement ne peuvent être laissés au hasard.

Keycloak as a Service est opéré sur des infrastructures européennes, dans un cadre conforme aux exigences réglementaires applicables. Cette approche garantit une meilleure maîtrise des données, une transparence accrue et une capacité d’audit essentielle pour les organisations soumises à des contraintes fortes.

L’open source joue ici un rôle central : il permet de comprendre, de vérifier et de faire évoluer les mécanismes de sécurité, sans dépendre d’une boîte noire technologique.

Une brique IAM adaptée aux architectures modernes

L’offre Keycloak as a Service s’intègre naturellement dans des architectures cloud natives, qu’il s’agisse d’applications web, de microservices ou d’API.

Elle permet d’unifier la gestion des accès entre des applications hétérogènes, de simplifier l’expérience utilisateur via le SSO et de renforcer la cohérence globale du système d’information.

Pour les équipes techniques comme pour les décideurs, cela se traduit par une meilleure lisibilité, une réduction des risques et une gouvernance des accès plus robuste.

Une démonstration en live est prévue le 26 février à 13 sur Twitch et Youtube, animée par Horacio Gonzalez et Mathieu Passenaud de Please Open It.

Questions fréquentes autour de l’Identity Access Management

À quoi sert concrètement une solution d’Identity Access Management ?

Une solution d’Identity Access Management permet de centraliser et de sécuriser l’accès aux applications, aux services et aux données. Elle garantit que chaque utilisateur ou service dispose uniquement des droits nécessaires, tout en assurant une traçabilité complète des accès. L’IAM est à la fois un outil de sécurité, de conformité et de gouvernance du système d’information.

Quelle est la différence entre IAM et simple authentification ?

L’authentification ne répond qu’à une partie du problème : vérifier l’identité d’un utilisateur. L’Identity Access Management va plus loin en gérant les autorisations, les rôles, la fédération d’identités, le cycle de vie des comptes et l’audit des accès. C’est cette vision globale qui permet de sécuriser des environnements complexes.

Pourquoi choisir une solution IAM open source comme Keycloak ?

Une solution open source comme Keycloak repose sur des standards ouverts et transparents. Elle permet d’éviter l’enfermement propriétaire, de mieux comprendre les mécanismes de sécurité et de conserver une capacité d’évolution sur le long terme. C’est un choix particulièrement pertinent pour les organisations soucieuses de maîtrise technologique et de conformité.

Keycloak est-il adapté à des environnements d’entreprise complexes ?

Oui. Keycloak est largement utilisé dans des contextes d’entreprise, y compris pour des architectures distribuées et multi-applications. Il s’intègre avec les annuaires existants, supporte l’authentification forte et permet une gestion fine des rôles et des permissions.

Pourquoi opter pour un Keycloak managé plutôt qu’auto-hébergé ?

Un Keycloak managé permet de bénéficier de la solution sans en assumer la complexité opérationnelle. Hébergement, mises à jour, sécurité, disponibilité et sauvegardes sont pris en charge par l’opérateur. Les équipes peuvent ainsi se concentrer sur les usages, la configuration fonctionnelle et les intégrations applicatives.

Où sont hébergées les données d’identités avec Keycloak as a Service ?

Avec Keycloak as a Service, les données d’identités sont hébergées sur des infrastructures françaises opérées par Clever Cloud. Cela assure le respect des exigences réglementaires et renforce la maîtrise des données sensibles.

Dans des architectures distribuées, hybrides ou cloud native, la gestion des accès ne relève plus d’un simple paramétrage applicatif : elle devient un sujet d’architecture et de continuité d’activité. Les solutions IAM open source s’appuient sur des standards ouverts comme OpenID Connect, OAuth 2.0 ou SAML et permettent de conserver une maîtrise technique et une capacité d’audit du fonctionnement interne.

Choisir un IAM open source ne se limite pas à comparer des fonctionnalités. Plusieurs dimensions structurent réellement la décision : compatibilité avec les standards, capacité à centraliser l’authentification et les autorisations, maturité de l’écosystème, intégration dans des environnements Kubernetes ou hybrides, robustesse du modèle de gestion des rôles. À cela s’ajoute une question souvent sous-estimée : la manière dont la solution sera exploitée dans la durée. Le choix technologique et le modèle d’exploitation sont indissociables.

IAM open source : rôle architectural et contraintes d’exploitation

Un IAM centralise l’authentification, l’autorisation, la fédération d’identités, la gestion des rôles et la traçabilité des accès. Dans une architecture moderne, il devient un point de contrôle unique dont dépendent les applications connectées. Une indisponibilité de l’IAM peut empêcher l’accès à l’ensemble des services qui en dépendent.

L’open source apporte une transparence du fonctionnement interne et une indépendance vis-à-vis d’un éditeur propriétaire. Il permet de s’appuyer sur des standards éprouvés et largement documentés.

En revanche, lorsqu’une organisation exploite elle-même sa solution IAM, elle assume la gestion des mises à jour de sécurité, la rotation des certificats, la supervision du service, la sauvegarde des données, la mise en place de la haute disponibilité et la gestion des incidents. Cette responsabilité technique est structurelle. Elle découle du rôle critique de l’IAM dans le système d’information.

La question centrale devient donc organisationnelle : qui prend en charge cette exploitation dans la durée ?

Les 8 meilleures solutions IAM open source

1. Keycloak : un standard open source largement adopté

Keycloak est aujourd’hui l’un des IAM open source les plus déployés. Il repose sur OpenID Connect, OAuth 2.0 et SAML. Il permet de centraliser l’authentification et la gestion des autorisations pour des applications hétérogènes, qu’elles soient on-premises, cloud ou hybrides. Il prend en charge le Single Sign-On (SSO), la fédération avec LDAP ou Active Directory, l’authentification multi-facteurs et des services d’autorisation avancés. Son adoption importante en fait un socle technique de référence pour structurer une politique d’accès cohérente.

Avantages

• Standard open source mature ;
• Large adoption en entreprise ;
• Intégration LDAP / Active Directory ;
• Support SSO et MFA ;
• Fréquemment déployé dans des environnements conteneurisés, notamment Kubernetes ;
• Gestion fine des rôles et des permissions.

Limites

• Exploitation complexe en production ;
• Mises à jour sensibles nécessitant une expertise spécifique ;
• Supervision et haute disponibilité à structurer par l’équipe opérationnelle ;
• Compétences spécifiques nécessaires.

2. Authentik : IAM open source orienté modernité et flexibilité

Authentik est une solution IAM open source plus récente, orientée simplicité de déploiement et modernité d’interface. Elle propose une approche centrée sur l’expérience administrateur et la flexibilité des politiques d’accès. Elle supporte OIDC et SAML, et peut agir comme reverse proxy d’authentification. Son architecture est adaptée aux environnements conteneurisés et aux déploiements via Docker.

Avantages

• Interface d’administration moderne ;
• Support OIDC et SAML ;
• Propose un mécanisme de proxy provider permettant de sécuriser l’accès aux applications exposées via reverse proxy ;
• Déploiement Docker simplifié ;
• Policies déclaratives.

Limites

• Écosystème plus récent, avec moins de retours d’expérience en production à grande échelle ;
• Intégration LDAP / Active Directory moins mature, ce qui peut limiter l'adoption dans des SI d’entreprise existants ;
• Support multi-tenant limité : la gestion de plusieurs organisations clientes isolées dans une même reste parti
• Moins documenté sur des architectures fortement distribuées.

3. Authelia : couche d’authentification légère pour environnements contrôlés

Authelia est une solution d’authentification open source principalement utilisée comme couche d’accès sécurisée devant des applications web. Elle s’intègre généralement à des reverse proxies comme Nginx ou Traefik. Elle vise les environnements recherchant une authentification centralisée avec MFA, sans mettre en place un IAM complet. Elle convient particulièrement aux infrastructures internes ou auto-hébergées.

Avantages

• Solution légère ;
• MFA intégré ;
• Configuration déclarative ;
• Intégration simple avec Nginx / Traefik.

Limites

• Pas de gestion complète du cycle de vie des identités ;
• Pas conçu pour des architectures multi-tenant complexes ;
• Moins adapté aux environnements hybrides étendus.

4. Gluu / Janssen : standards avancés et conformité renforcée

Gluu et le projet Janssen proposent une solution IAM orientée standards avancés et conformité. Ils sont souvent utilisés dans des environnements nécessitant des protocoles spécifiques ou des exigences fortes en matière d’authentification. L’architecture est modulaire et supporte des mécanismes comme FIDO2 ou UMA. Cette richesse fonctionnelle s’accompagne d’une complexité d’intégration importante.

Avantages

• Support FIDO2 ;
• Architecture modulaire ;
• Fonctionnalités orientées conformité ;
• Gestion avancée des autorisations.

Limites

• Complexité élevée ;
• Installation lourde ;
• Courbe d’apprentissage importante.

5. WSO2 Identity Server : IAM complet dans un écosystème intégré

WSO2 Identity Server est une solution IAM complète intégrée dans un écosystème plus large de services d’intégration et d’API management. Elle cible principalement des architectures d’entreprise complexes. Elle propose une gestion avancée des politiques d’accès, des workflows d’identité et des mécanismes de fédération étendus.

Avantages

• Gestion avancée des politiques ;
• Support multi-protocoles ;
• Intégrations étendues ;
• Fonctionnalités enterprise.

Limites

• Stack lourde ;
• Courbe d’apprentissage élevée ;
• Configuration importante ;
• Complexité opérationnelle.

6. FusionAuth (Community) : intégration rapide et API-first

FusionAuth propose une édition Community gratuite distribuée sous licence FusionAuth, contrairement aux autres solutions de cette liste qui sont open source. Le projet adopte un modèle distinct des licences open source classiques de type OSI. Il cible notamment les éditeurs SaaS et les équipes souhaitant intégrer rapidement une brique d’authentification. La version Community permet un déploiement autonome, avec une interface claire et des mécanismes multi-tenant.

Avantages

• Approche API-first ;
• Interface claire ;
• Multi-tenant ;
• Installation rapide.

Limites

• Cœur applicatif propriétaire et source-fermée : pas d'audit possible du code principal ;
• Le modèle de licence distingue l’édition Community des éditions commerciales, ce qui peut limiter l’accès à certaines fonctionnalités avancées selon le périmètre d’usage ;
• Moins répandu dans des environnements réglementés complexes.

7. Ory : IAM cloud-native modulaire

Ory est une suite de composants IAM cloud-native. Elle adopte une architecture microservices, avec des briques distinctes pour l’identité, l’authentification et les autorisations. Cette approche headless s’intègre bien dans des environnements Kubernetes et DevOps avancés, mais nécessite l’assemblage de plusieurs composants.

Avantages

• Architecture modulaire ;
• Compatible Kubernetes ;
• Approche headless ;
• Intégration DevOps forte.

Limites

• Assemblage nécessaire ;
• Complexité d’intégration ;
• Pas de solution monolithique prête à l’emploi.

8. Zitadel : IAM multi-tenant orienté SaaS

Zitadel est un IAM cloud-native orienté SaaS et multi-tenant. Il adopte une approche OIDC-first et cible les architectures modernes nécessitant isolation et segmentation des clients. Sa conception est adaptée aux plateformes multi-clients et aux environnements distribués.

Avantages

• OIDC-first ;
• Multi-tenant natif ;
• Interface moderne ;
• Adapté aux architectures SaaS.

Limites

• Projet distribué sous licence AGPL v3 depuis la version 3 (mars 2025) : l'usage standard en production sans modification du code n'est pas affecté, mais toute modification du code source (backend Go, schéma de base de données) ou intégration étroite dans un produit tiers oblige à publier le code sous AGPL ou à souscrire une licence commerciale ;
• Écosystème plus récent que Keycloak ;
• Moins répandu que Keycloak en environnements d’entreprise établis.

Quel est le meilleur IAM open source ?

Le meilleur IAM open source dépend du contexte technique, du niveau de maturité opérationnelle et du modèle d’exploitation retenu. Keycloak reste aujourd’hui la référence open source mature et standardisée. La différenciation porte ensuite sur la manière dont il est exploité. Le choix ne se limite donc pas au logiciel. Il concerne la capacité à maintenir le service dans le temps, à absorber les mises à jour et à garantir la disponibilité.

Le tableau ci-dessous compare les principales caractéristiques techniques des solutions open source analysées. Il permet d’identifier les différences de standards supportés, d’architecture et de complexité d’exploitation.

Exploiter un IAM open source : auto-opéré ou managé ?

Une fois la solution IAM choisie, une question structurante demeure : qui prend en charge son exploitation ?

Un déploiement auto-opéré implique la gestion des mises à jour, la supervision, la haute disponibilité, la gestion des certificats et la résilience. Un modèle managé transfère cette responsabilité à un opérateur, tout en conservant la gouvernance fonctionnelle côté organisation. Il implique néanmoins une dépendance au fournisseur pour l’exploitation de la plateforme et un coût récurrent associé au service.

Dans le cas de Keycloak, Clever Cloud propose une version managée reposant sur le socle open source. Les mises à jour de sécurité, la supervision et la disponibilité sont prises en charge par la plateforme, tandis que l’organisation conserve l’accès à l’interface d’administration standard.

Conclusion

Un IAM open source structure durablement la gestion des accès et renforce la gouvernance des identités. Il constitue une brique critique de sécurité et de conformité.Dans ce paysage, Keycloak offre une base solide et standardisée. Un modèle managé permet d’aligner ouverture technologique, maîtrise des risques et exploitation industrielle. Clever Cloud s’inscrit dans cette approche : maintenir le standard open source, tout en en assurant l’exploitation dans un environnement hébergé en Europe et opéré dans un cadre certifié ISO 27001.