Blog /

Rix, ce n'est pas une boîte qu'on a « décidé » de créer un matin sur un coin de table. C'est une expertise qui a grandi chez Elao pendant des années, jusqu'à ce qu'elle réclame son propre véhicule. Voilà pourquoi - et comment - on a fini par franchir le pas.

L'origine : une expertise qui s'est imposée naturellement

Tout au long des 15 années d'existence d'Elao (à l'époque) qui, historiquement, a toujours été un atelier de conception d'applications web métier, les compétences sysadmin déjà présentes se sont développées progressivement, presque organiquement.

Au départ, ce n'était pas une volonté stratégique. C'était une réponse à un besoin concret : certains de nos clients ne disposaient ni de compétences infrastructure en interne, ni de prestataire identifié pour gérer l'exploitation de leur applicatif métier. D'autres préféraient simplement avoir un interlocuteur unique pour tout ce qui touchait au logiciel, du code jusqu'à la production.

Et si un hébergeur pour un site institutionnel se trouve relativement facilement, lorsque le besoin est un peu technique avec des contraintes plus fortes que « juste une présence » en ligne, à quoi s'ajoute la nécessité de comprendre un métier pour pouvoir décider de ce qui est important (d'un point de vue de l'exploitation), c'est un poil plus compliqué.

Et enfin, il est vrai que souvent, la confiance s'étant installée, on nous demandait si on ne pouvait pas « dépanner ». Sauf que « dépanner », on ne sait pas trop faire. Quand on fait un truc, on a la fâcheuse tendance de le faire à fond.

Et comme nous avions des profils à double casquette sysadmin / dev (on ne parlait encore pas trop de devops à l'époque)... forcément, on ne s'est pas trop fait prier.

Nous avons donc appris, expérimenté, structuré nos pratiques (on s'est bien évidemment plantés aussi, mais toujours de façon « relativement maîtrisée », je vous laisse mettre ce que vous voulez derrière ce « relativement » 😅). Ce qui était au départ un service « complémentaire » est rapidement devenu une véritable expertise.

Pas par la compétence technique pure - bien que ça ait toujours été un point fort - mais plutôt par la compréhension du besoin et de la contrainte de l'exploitation. On en reparlera, mais ces deux axes sont fondamentaux lorsque l'on doit construire une réponse pour un client et l'accompagner correctement.

Cet héritage est toujours vivant : aujourd'hui encore, la moitié de l'équipe Rix a connu cette genèse au sein d'Elao. Cette continuité n'est pas anecdotique. Elle signifie que les bases fondatrices d'Elao irriguent naturellement notre façon de travailler.

Un ADN forgé par l'autonomie

Elao s'est construite sur un modèle proche de ce qu'on appelle - avec toutes les réserves que ce terme trop souvent galvaudé impose - une « entreprise libérée ». Si l'on doit la résumer succinctement, je la décrirais comme une organisation fondée sur la confiance accordée rapidement, l'autonomie dans la gestion de manière générale et la responsabilisation individuelle.

Ce choix assumé a été fondateur et est toujours partagé avec Xavier encore aujourd'hui.

Je n'ai découvert que tardivement, il y a une dizaine d'années, les travaux de Jean-François Zobrist, que je cite souvent, et son expérience chez FAVI. Mais en le lisant, en l'écoutant lors de ses nombreuses et précieuses interventions, j'ai réalisé que nous avions intuitivement adopté des principes similaires : faire confiance a priori, supprimer les contrôles inutiles, responsabiliser plutôt que surveiller.

Ce n'était pas une application consciente d'une méthode ; c'était simplement notre façon naturelle de fonctionner. Et aussi, j'en suis persuadé, une incapacité profonde à penser et fonctionner autrement. Je ne parviens absolument pas à imaginer un fonctionnement où la confiance n'est pas fondatrice de tout le reste.

« Naïf, car je crois que l'homme est bon, donc je ne contrôle rien. Paresseux, car j'ai tendance à ne pas régler les problèmes, mais à les supprimer, et cela devient une force. »

Jean-François Zobrist

Constater cette convergence n'était finalement qu'une évidence, aussi éloignés que soient nos domaines d'activité respectifs.

Une de ses formules résume bien notre philosophie : « Ceux qui savent sont ceux qui font. » Chez nous, les décisions techniques sont prises par ceux qui les exécutent car c'est eux qui auront la responsabilité de les maintenir. Pas de validation hiérarchique superflue, pas de comité qui tranche à la place de l'équipe terrain. On discute tous ensemble des orientations techniques qui fonderont les bases de notre façon de travailler de demain.

À ceux qui y verront un défaut de contrôle et d'organisation, c'est tout l'inverse. Les choses importantes ne reposent plus sur le sommet d'une pyramide mais s'appuient sur un socle solide et bien large (en opinions, en divergences et en connaissances). L'information ne descend pas, elle remonte. Fonctionnement qui a en plus le mérite d'atténuer le problème de l'homme clé puisque la connaissance est diffusée et portée par tous.

Autre héritage d'Elao, qui rejoint encore une fois les réflexions de Zobrist : le besoin d'un contact le plus direct possible avec le client final. Chez Rix, notre « client final » est souvent l'équipe technique - les devs, les leads tech, les CTO. Ce sont eux qui vivent au quotidien avec l'infrastructure que nous gérons. Interposer des couches intermédiaires, des chefs de projet qui filtrent les échanges, du support N1, N2, N3… c'est perdre en réactivité et en pertinence. Nous préférons parler directement aux équipes côté client, pour mieux comprendre leurs contraintes et y répondre au plus juste.

Alors oui, parfois ça génère du volume de support pas forcément justifié, mais sur le long terme, en formant les équipes de nos clients, en expliquant pourquoi tel choix, on constate que ce volume se lisse et se normalise. Parce que oui, la formation et la montée en compétence des équipes clientes sont importantes, et surtout parce que nous ne nous voyons pas comme un prestataire vers lequel on se débarrasse d'une responsabilité, au contraire, nous la partageons.

Chez nous, personne n'attend qu'on lui dise quoi faire. Chacun est acteur de son périmètre, libre d'expérimenter, d'adapter son rythme, voire de faire évoluer son poste. Cette liberté a une contrepartie : elle exige de la proactivité et une capacité à se structurer soi-même.

Du côté de la structure, il est indispensable d'accepter l'échec et d'intégrer le droit de se tromper dans la culture même des équipes. Cette démarche nécessite aussi de mettre en place l'organisation qui permet, quand boulette il y a, d'en contenir les conséquences - sans nous impacter, et encore moins nos clients.

L'esprit d'équipe compense ce qui pourrait devenir de l'isolement. Le partage de connaissances est systématique : code reviews, pair programming, échanges techniques constants. La transmission n'est pas optionnelle, c'est le ciment du collectif. La bienveillance (tiens, encore un buzzword) non plus : accepter les forces et les faiblesses de chacun fait partie du contrat implicite.

Cette culture, Rix l'a héritée mais l'entretient et la défend farouchement. Elle structure notre rapport au travail, à nos clients, et bien évidemment, entre nous.

Le constat : des besoins clients qui évoluent

Après cette longue mais nécessaire présentation, revenons au sujet qui nous intéresse. Au fil des années, les demandes de nos clients se sont intensifiées. Ce qui relevait autrefois de coups de main ponctuels est devenu un besoin structurel : des infrastructures plus complexes, des exigences de disponibilité plus élevées, des contraintes réglementaires croissantes (et ce n'est pas le contexte actuel qui va me faire mentir ! NIS2, AI Act, Cyber Resilience Act, DORA…), choisissez votre poison ☠️ 😉.

Nous avons commencé à structurer notre offre d'hébergement et d'infogérance pour y répondre. D'abord de manière artisanale, puis de plus en plus formalisée et industrialisée. Les pratiques DevOps se sont imposées comme un standard (ça n'a pas été bien compliqué vu nos origines). L'observabilité est passée du « nice to have » au prérequis. La sécurité, la sûreté et la gouvernance des infrastructures et des données sont rapidement devenues un sujet central.

Progressivement, une équipe dédiée s'est constituée au sein d'Elao. Des profils qui consacraient l'essentiel de leur temps aux infrastructures, aux environnements de développement, aux pipelines CI/CD, au monitoring, à la gestion des incidents. Une équipe Ops à part entière, avec ses compétences propres et ses problématiques spécifiques.

La décision : structurer pour mieux servir

À un moment, il a fallu se rendre à l'évidence : notre héritage nous donnait peut-être une vision de l'exploitation trop orientée dev et pas assez infra. On maîtrisait le code, les déploiements, l'intégration continue - mais on abordait parfois les problématiques d'infrastructure avec des réflexes de développeurs.

Côté clients, la confusion s'installait. Étions-nous des devs qui faisaient de l'infra ? Ou des ops qui faisaient du dev ? Dans les deux cas, le message était flou. Et un positionnement flou, c'est une crédibilité fragilisée (légitime ou pas).

L'autre déclencheur a été l'arrivée de nouveaux clients : d'autres agences web, parfois similaires à Elao, qui nous sollicitaient pour leurs problématiques d'infrastructure. Travailler pour des structures potentiellement concurrentes créait parfois une ambiguïté où personne n'était vraiment à l'aise, ni les clients, ni nous.

Et puis, après plusieurs années d'exploitation d'applications critiques et exigeantes, nous avions aussi la prétention assumée d'avoir fait mûrir de vraies compétences. Pas juste des devs qui savent administrer un serveur, mais une approche métier de l'exploitation : gestion des incidents, capacity planning, SLO, post-mortems. Un savoir-faire qui méritait d'être reconnu comme tel, mais surtout de disposer de son propre véhicule.

La solution s'est imposée : créer une entité distincte, avec son identité propre (un jour je vous expliquerai ce cheminement aussi 😉), son positionnement clair, et sa relation client autonome.

La décision a mûri pendant près d'un an. Et puis en 2020, en plein premier confinement, nous avons décidé de nous lancer. Le timing peut sembler paradoxal, mais l'élan comme l'envie étaient là et parfois il est important de laisser des chances au hasard, respecter ses intuitions et passer de l'intuition à l'action.

Le premier défi a donc été de créer la structure juridique entièrement à distance.

Notre dernier exercice remontant à près de 15 ans, on ne peut pas dire que c'est rempli de certitudes qu'on a lancé la machine, mais au final ça a été bien plus rapide que prévu.

Certificat dépositaire reçu de la banque le 27 mars, immatriculation le 31 mars, Kbis en main le 1er avril (oui, j'ai revérifié mes courriels). Cinq jours. Là où je ne suis souvent pas le dernier à critiquer la lenteur lourdeur de l'administration française, force est de reconnaître que je n'ai pas eu grand-chose à en redire.

Rix aujourd'hui

Six ans après ce Kbis reçu le 1er avril 2020, Rix c'est cinq personnes. Cinq personnes qui, pour une grande majorité, ont commencé leur carrière côté dev avant de basculer Ops. Ce n'est pas un détail de CV : c'est ce qui change concrètement la façon dont on travaille.

Un exemple qui revient souvent : quand un client vient nous voir parce qu'un déploiement en prod tourne mal, on ne lit pas seulement les métriques du cluster. On relit aussi la logique applicative derrière, on demande ce qui a changé dans le code, on interroge également notre compréhension du métier car le problème n'est pas forcément (que) technique. C'est parfois (souvent) un changement fonctionnel qui déclenche un problème technique qui jusqu'à présent n'avait pas été identifié. La fameuse requête N+1 qui passait sous les radars en dev et qui s'effondre sous la charge réelle. Sans ce double voire triple regard, on passe à côté. Avec, on gagne littéralement des heures.

C'est aussi ça que nous a amené cette autonomie, la possibilité de se frotter à d'autres approches, d'autres méthodes de travail. Être challenger sur des problématiques que nous n'aurions pas forcément eues.

C'est ce qu'apporte la double vision : pas une promesse marketing, mais une façon de poser les questions différemment dès le départ et puis, on ne va pas se mentir, le résultat d'une longue expérience à se prendre les mêmes murs que nos clients d'aujourd'hui. Parce que les technos évoluent certes mais on en revient quand même très régulièrement aux bases du fonctionnement de tout ce beau monde.

Ce qui nous distingue

Une équipe qui connaît ses infrastructures par cœur. On n'a « perdu » personne depuis la création. Zéro turnover en six ans, ce qui dans notre secteur relève davantage de l'exception que de la règle. Concrètement : quand vous nous appelez, il y a de bonnes chances que cela soit quelqu'un qui a posé les bases de votre infra il y a trois ans qui décroche. C'est d'ailleurs souvent avec fierté que l'on constate que 90 % de nos clients sont là depuis plus de cinq ans - eux aussi.

Un accès direct aux gens qui font. Pas de chef de projet interposé, pas de support à tiroirs. Vous échangez avec ceux qui opèrent réellement votre infrastructure. C'est un choix délibéré, pas une contrainte de taille : on l'a maintenu même quand ça générait du volume de support. Parce qu'on a constaté qu'en parlant directement aux équipes techniques de nos clients, en expliquant les pourquoi, ce volume finit par se normaliser - et nos clients montent en compétences au passage.

Un positionnement souverain qui ne s'excuse pas. Nos infrastructures sont principalement chez OVHcloud, avec qui nous travaillons depuis plus de 15 ans et dont nous sommes partenaires certifiés. Nous savons également travailler avec Scaleway, GCP ou AWS quand le contexte l'exige ou lorsque c'est le choix de nos clients.

Mais notre position par défaut est claire et assumée : gouvernance française, données qui restent en Europe, fournisseur dont on connaît les équipes. Dans le contexte actuel, ce n'est plus juste un parti pris éthique, c'est une exigence de plus en plus fréquente chez nos clients.

La réversibilité comme ligne rouge. Chaque infrastructure est conçue pour que vous puissiez reprendre la main ou changer d'hébergeur sans nous devoir quoi que ce soit. Pas de configuration propriétaire enfouie, pas de dépendance artificielle à nos outils. En tant que contributeur (modeste) à l'Open Source, nous avons à cœur de préserver au maximum l'indépendance technologique de nos clients.

La sécurité, pas comme une case à cocher. Veille CVE permanente, renseignement sur les menaces (flux d'IOC, avis CERT-FR) croisé avec notre supervision, mises à jour hebdomadaires, culture du post-mortem depuis le premier jour. Ce n'est pas nouveau pour nous - c'est simplement comme ça qu'on a toujours travaillé. En 2026, on franchit l'étape suivante avec notre démarche de certification ISO 27001/HDS : formaliser ce qu'on fait déjà, le rendre auditable, et être en mesure de le prouver.

Six ans de recul suffisent pour le dire sans forfanterie : on a construit quelque chose qui tient. La question, maintenant, c'est jusqu'où on l'emmène.

Et demain ?

Jusqu'où on l'emmène. La question est posée, et on va essayer d'y répondre honnêtement - sans sur-promettre et sans se défiler.

Le premier cap est déjà tracé : la certification ISO 27001/HDS que nous visons n'est pas une fin en soi, c'est un moyen. En nous certifiant, nous voulons pouvoir accompagner des structures qui ont des exigences de conformité - santé, finance, secteur public, ou des clients qui l'imposent, ou encore de simples préoccupations légitimes quant à la qualité des services rendus par leur prestataire - sans avoir la taille, la culture ou les moyens d'aller chez un gros acteur certifié. Être ce partenaire de confiance qui offre les mêmes garanties que de plus grosses structures, mais qui reste à leur échelle : de la proximité, de la pédagogie, un interlocuteur qui parle leur langue et qui est proche des équipes internes.

Le deuxième cap est technique, et c'est celui qui nous passionne le plus : pousser notre culture SRE au niveau supérieur. Pas « faire de l'observabilité » comme un point d'étape, mais traiter l'observabilité comme un produit à part entière - revues annuelles avec nos clients, rapport régulier des actions faites, bref fournir un peu plus d'éléments décisionnels à ceux qui sont le plus concernés. On sait diagnostiquer vite et bien parce qu'on connaît les infras qu'on opère par cœur. L'enjeu des prochaines années, c'est de rendre cette capacité reproductible, traçable, transmissible - indépendante des personnes qui la portent.

Le troisième cap, c'est la croissance de l'équipe - et c'est probablement le plus délicat. On envisage un ou deux recrutements à horizon 2-3 ans. Pas d'inflation, pas de croissance pour la croissance. Le défi est simple à énoncer et difficile à tenir : intégrer sans casser ce qui fonctionne. La double culture dev/ops, la transmission par l'exemple, le contact direct avec les clients - tout ça ne se scale pas mécaniquement. On réfléchit à comment embarquer les nouveaux arrivants dans cette culture sans la diluer. L'objectif final étant bien évidemment d'augmenter encore notre capacité à mieux répondre à ceux qui font appel à nous.

Le quatrième cap, on tâtonne encore : l'IA en appui des opérations. Outillage interne, aide au diagnostic d'incident, automatisation des réponses récurrentes. On expérimente. On ne sait pas encore très bien où ça va nous mener, et on se méfie des effets d'annonce. Mais le sujet est là, il est réel, et feindre de l'ignorer serait une forme de naïveté qu'on ne peut pas se permettre.

D'autant que les copains chez Elao sont très en avance sur ce sujet et qu'ils ont plein de choses à nous apprendre. Pour les curieux, Xavier, qui pilote Elao, a donné plusieurs conférences sur l'impact de l'IA au sein des équipes et dans le métier de la conception applicative, dont celle-ci à l'Agile Tour Strasbourg.

Si vos infrastructures nécessitent ce niveau d'attention, vous savez où nous trouver. 😉

Pour en savoir plus sur les petits patrons naïfs et paresseux

Si les principes évoqués dans cet article vous ont interpellé, les ouvrages de Jean-François Zobrist offrent une plongée approfondie dans cette philosophie managériale :

« L'entreprise libérée par le petit patron naïf et paresseux » (2020) - Le récit fondateur de l'expérience FAVI, où Zobrist raconte comment il a transformé une fonderie industrielle en supprimant les contrôles, en faisant confiance aux équipes et en responsabilisant chaque acteur. Éditions Le Cherche Midi

« La belle histoire de FAVI : L'entreprise qui croit que l'homme est bon » (Tome 1 : Nos belles histoires, 2013 et Tome 2 : Notre management et notre organisation, 2014) - Une exploration détaillée des pratiques concrètes mises en place chez FAVI, avec de nombreux exemples et retours d'expérience. Éditions Humanisme & Organisations

Ces lectures ne sont pas des manuels de management à appliquer mécaniquement. Ce sont des témoignages d'une approche différente, fondée sur la confiance a priori plutôt que sur le contrôle. Une approche qui, comme nous l'avons découvert, peut émerger naturellement quand on accepte de faire confiance à ceux qui font.