Une production sérieuse, tenue par une personne

Il y a une conversation qui revient à peu près tous les mois dans les startups que j'accompagne. Le produit marche, les clients arrivent, et quelqu'un finit par poser la question à voix haute : « il nous faudrait un SRE, non ? ». La réponse est presque toujours plus intéressante que la question, parce qu'elle oblige à formuler ce que personne n'a formulé jusque-là : qu'est-ce qu'on entend, exactement, par « être en production » ?

Ce guide s'adresse au CTO, au lead technique ou au fondateur technique qui doit tenir une production sérieuse sans avoir d'équipe ops derrière lui. Il ne vend pas l'idée qu'on peut se passer d'expertise infrastructure. Il défend une thèse plus étroite et, je crois, plus utile : le seuil à partir duquel une infrastructure de qualité industrielle devient accessible à une petite équipe a bougé, très vite, ces deux dernières années. Ce qui demandait trois mois à deux SRE il y a un an tient aujourd'hui dans une dizaine d'heures de travail humain. Pas parce que le métier a disparu, mais parce que l'outillage a changé de nature.

Le fil rouge de ce guide est constant : le vrai sujet n'est jamais la vitesse, c'est la qualité. Une infra montée vite et mal est un passif qui vous coûtera bien plus cher que les six mois de salaire que vous pensiez économiser.

Avez-vous vraiment besoin d'un SRE ?

Commençons par la question qui économise le plus d'argent, parce qu'elle a une réponse chiffrable.

Le rôle de SRE — Site Reliability Engineer — n'est ni un administrateur système rebaptisé, ni un « DevOps » de plus dans l'équipe. C'est un métier avec ses propres objets : définir des objectifs de fiabilité mesurables, gérer un budget d'erreur, réduire le travail répétitif, piloter les incidents. J'ai détaillé cette distinction et les confusions qu'elle génère dans un article dédié au rôle du SRE, parce que le recrutement se rate presque toujours sur ce malentendu : on cherche un SRE, on recrute un admin sys, et personne n'est content six mois plus tard.

Les seuils, tels que je les observe sur le terrain :

Sous dix développeurs, presque jamais. À cette taille, le volume d'incidents ne justifie pas un poste. Un SRE recruté trop tôt s'ennuie, dérive vers du support ou de l'outillage interne, et part au bout d'un an. Ce que vous cherchez à ce stade, ce n'est pas un poste, c'est un socle : une infrastructure suffisamment ennuyeuse pour ne pas réclamer d'attention quotidienne.

Entre dix et trente développeurs, les signaux d'alerte. Ils sont assez reconnaissables : les déploiements deviennent des événements qu'on redoute, quelqu'un dans l'équipe est devenu le seul à savoir redémarrer tel service, les incidents se répètent sans que personne n'ait le temps d'en traiter la cause, et les astreintes se font au feeling. Ce n'est pas encore un poste plein, mais ce n'est plus tenable en pointillé.

Au-delà de trente développeurs, c'est structurel. Le nombre de services, de dépendances et de déploiements quotidiens crée un travail de fiabilité à temps plein. La question n'est plus « faut-il un SRE » mais « combien, et rattachés à qui ».

L'erreur classique n'est pas de recruter trop tard. C'est de recruter pour combler un manque d'outillage. Un SRE embauché pour compenser une infrastructure bricolée passera ses journées à éteindre des feux qu'un socle correct n'aurait jamais allumés, et vous aurez payé un salaire senior pour ne pas résoudre le problème.

Ce qu'« être en production » exige vraiment

C'est le point où beaucoup d'équipes se racontent des histoires, et c'est aussi le plus facile à objectiver. Voici ce qu'une production sérieuse suppose, indépendamment de la taille de l'équipe. Chacun de ces points est non négociable, et l'absence d'un seul suffit à transformer un incident ordinaire en très mauvaise semaine.

La haute disponibilité réelle. Pas « on a un serveur costaud », mais : une machine peut disparaître sans que le service s'arrête. En pratique, cela veut dire au minimum trois nœuds, parce que le plan de contrôle a besoin d'un quorum pour continuer à décider quand un membre tombe. Deux machines ne donnent pas de la redondance, elles donnent deux points de défaillance et une illusion.

Des sauvegardes testées. La sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde, c'est une croyance. J'insiste parce que j'ai vu le cas de près : un mécanisme de sauvegarde qui tournait consciencieusement toutes les nuits, sans écrire un octet nulle part, pendant sept semaines. En silence. Le job existait, les logs étaient verts, et il n'y avait rien au bout. La seule parade est la restauration périodique, réellement exécutée.

L'observabilité. Savoir ce qui se passe, et être prévenu quand ça casse — avant le client, idéalement. Métriques, logs centralisés, alertes qui arrivent sur un canal que quelqu'un lit vraiment. Une alerte qui part dans une boîte mail que personne n'ouvre est un coût sans bénéfice.

Un état déclaré, pas bricolé. Si la configuration de votre production vit dans l'historique de commandes de quelqu'un, vous ne pouvez ni la reconstruire, ni la revoir, ni savoir qui a changé quoi. L'approche GitOps résout ça d'une manière brutalement simple : ce qui n'est pas dans Git n'existe pas. Le dépôt devient la source de vérité, et la machine se charge de faire converger la réalité vers ce qui y est écrit.

Des données opérées, pas installées. Une base de données de production a besoin de sauvegardes, de bascules, de mises à jour de version et de surveillance. L'installer à la main sur une machine, c'est signer pour tout faire soi-même, à vie.

J'ai décrit l'anatomie complète d'une plateforme qui coche ces cinq cases dans un article détaillé sur un cluster Kubernetes de production : le système d'exploitation immuable, le réseau, le GitOps, les bases opérées, l'observabilité et la stratégie de survie aux catastrophes. C'est volontairement technique, et c'est la référence à laquelle je renvoie quand on me demande à quoi ressemble « sérieux » concrètement.

Quel socle choisir : bare-metal, cloud managé ou PaaS

Le choix du socle est celui qui a le plus d'impact sur votre facture, et le plus de mythologie autour de lui.

Socle	Ce qu'il coûte	Ce qu'il demande	Quand il s'impose
PaaS (déploiement clé en main)	Le plus cher au To et au CPU	Presque rien	Démarrage, MVP, petite équipe sans compétence infra
Cloud public managé	Élevé, et croissant avec le succès	Une vraie compétence cloud	Charge très variable, besoin de services managés exotiques
Bare-metal orchestré	Le plus bas, de loin	Une compétence infra réelle	Charge prévisible, coûts qui dérapent, besoin de souveraineté

L'ordre de grandeur mérite d'être posé, parce qu'il surprend souvent : trois serveurs dédiés totalisant 192 Go de mémoire et une vingtaine de processeurs coûtent environ cent euros par mois. L'équivalent en cloud public managé tourne autour de mille euros mensuels, hors frais de réseau — et ce sont précisément ces frais de sortie qui transforment une facture prévisible en mauvaise surprise trimestrielle. J'ai détaillé ce montage et son coût réel dans Kubernetes sur bare metal, une infra résiliente à 100 € par mois.

Cela ne fait pas du bare-metal la bonne réponse par défaut. Il y a deux conditions à réunir, et elles sont exigeantes.

La première est la prévisibilité de la charge. L'élasticité du cloud se paie très cher ; elle ne vaut son prix que si vous en avez réellement besoin. Un SaaS B2B dont le trafic suit les heures de bureau européennes n'a pas besoin de pouvoir décupler sa capacité en trois minutes.

La seconde est la compétence disponible. Et c'est ici que le paysage a changé. Monter cette plateforme demandait trois mois à deux SRE il y a un an ; avec de l'assistance de complétion classique, un développeur senior y arrivait en trois semaines ; aujourd'hui, avec de l'IA agentique et l'expérience accumulée, le travail humain effectif tient dans une dizaine d'heures. Le temps d'horloge reste plus long — quelques jours — mais c'est de l'attente : la livraison des serveurs, la propagation DNS, l'émission des certificats. De l'attente qui n'occupe pas vos mains.

Un avertissement, parce qu'il est essentiel et qu'il est systématiquement escamoté : ces dix heures ne sont accessibles qu'à quelqu'un qui sait ce qu'il fait. L'IA n'invente pas l'expertise infrastructure, elle l'amplifie — j'en ai fait un article entier parce que c'est le cœur du malentendu actuel. Sans bagage, elle vous produira un cluster qui a l'air de fonctionner et qui s'effondrera au premier incident réel. La différence entre une démonstration et une production, ce sont exactement les galères qu'on a traversées pour y arriver.

La stack, composant par composant

Une plateforme de production n'est pas un produit qu'on achète, c'est un assemblage de briques dont chacune résout un problème précis. Voici les cinq couches, et surtout la question à laquelle chacune répond — parce que c'est cette question qu'il faut se poser avant de choisir l'outil.

Le système d'exploitation : « qui peut modifier mes serveurs ? » Un système immuable, sans accès interactif ni gestionnaire de paquets, répond de la manière la plus radicale : personne, pas même vous. Toute la configuration passe par une API déclarative. On perd le confort de se connecter en urgence pour bricoler ; on gagne l'assurance qu'aucune machine ne dérive silencieusement de ses voisines. C'est exactement le compromis qu'on veut faire quand on n'a personne pour tenir le registre des bricolages.

Le réseau : « comment mes services se parlent-ils, et qui peut leur parler ? » C'est la couche la plus souvent sous-estimée et la plus douloureuse à reprendre après coup. Deux besoins s'y croisent : router le trafic entrant vers le bon service, et cloisonner les services entre eux pour qu'une compromission ne se propage pas. Traiter le second besoin dès le départ coûte quelques heures ; le traiter après un incident coûte beaucoup plus.

Le stockage : « où vivent les données qui doivent survivre ? » Un conteneur est éphémère par construction ; vos données ne le sont pas. Il faut donc une couche de stockage répliquée qui suive un service quand il change de machine, et qui survive à la perte d'un serveur. C'est la brique où l'on rogne le plus volontiers, et celle dont les défaillances sont les moins réversibles.

Le déploiement : « qu'est-ce qui tourne, et qui l'a décidé ? » L'approche GitOps répond aux deux d'un coup : l'état désiré est décrit dans un dépôt, un agent fait converger la réalité vers cette description, et l'historique Git devient le journal des décisions. Le bénéfice qu'on sous-estime n'est pas l'automatisation, c'est la revue : un changement d'infrastructure passe par une pull request, donc par un regard.

L'observabilité : « comment saurai-je que ça casse ? » Métriques, logs centralisés, et surtout des alertes qui atterrissent sur un canal réellement lu. Le piège n'est pas l'absence d'alertes, c'est leur excès : une équipe qui reçoit quarante notifications par jour cesse de les lire au bout d'une semaine, et l'alerte qui comptait passe avec les autres.

Le point commun de ces cinq couches, c'est qu'aucune n'est optionnelle en production, et qu'aucune ne demande une équipe pour être mise en place aujourd'hui. Ce qu'elles demandent, c'est de savoir pourquoi on les met en place — d'où l'insistance sur la question plutôt que sur l'outil.

Ce qu'il ne faut surtout pas automatiser tout de suite

Il y a un réflexe, chez les équipes qui découvrent qu'elles peuvent aller vite, qui consiste à tout industrialiser d'un coup. C'est le meilleur moyen de se construire une deuxième base de code à maintenir, avec ses propres bugs, sa propre dette et personne pour s'en occuper.

Le critère est simple et se calcule au dos d'une enveloppe : que gagne-t-on à automatiser ceci ? Une tâche exécutée deux fois par an, en dix minutes, ne justifie pas trois jours d'automatisation et une maintenance perpétuelle. Une tâche exécutée à chaque déploiement, oui, immédiatement.

L'alternative pragmatique tient en deux temps. On documente d'abord : une procédure écrite, suivie à la lettre, reproductible par quelqu'un d'autre. On script ensuite, une fois que la procédure s'est stabilisée et qu'on a la certitude d'automatiser la bonne chose. L'automatisation prématurée fige une procédure qu'on n'a pas encore comprise.

C'est la thèse que je développe dans Terraform : avez-vous vraiment besoin d'automatiser votre infrastructure ?, et elle vaut au-delà de cet outil particulier. Le moment où l'outillage devient un must-have est assez net : plusieurs environnements à maintenir identiques, plusieurs personnes qui modifient l'infrastructure, ou une obligation de traçabilité. Avant ça, le coût dépasse le bénéfice.

Le travail invisible : les mises à jour

Voilà le poste que personne ne budgète et qui décide, plus que le montage initial, si votre infrastructure sera encore saine dans deux ans.

Une plateforme moderne, c'est une dizaine de composants qui publient chacun plusieurs versions par an, avec des cycles de support qui expirent. Un composant en fin de vie ne cesse pas de fonctionner du jour au lendemain : il cesse simplement de recevoir des correctifs de sécurité, et vous ne l'apprenez qu'au moment où une faille publique circule. Le coût de la mise à jour, lui, croît de façon non linéaire avec le retard accumulé : monter d'une version mineure est une formalité, en rattraper quatre est un projet.

La discipline qui marche tient en trois règles simples.

Monter régulièrement plutôt que rarement. Une fenêtre courte tous les mois vaut mieux qu'un grand chantier annuel. Le volume de changement à absorber reste petit, donc le risque aussi, et l'équipe garde le geste.

Vérifier par l'exécution, pas sur les notes de version. Les changements qui cassent en silence sont rarement ceux qui sont documentés : une politique réseau appliquée par défaut, une ressource supprimée parce qu'elle n'apparaît plus dans le rendu, un volume qui n'est pas migré automatiquement. Rien de tout cela n'échoue bruyamment. Le seul contrôle fiable est de regarder l'état réel après coup.

Traiter la sécurité comme une mise à jour, pas comme un incident. Les correctifs de sécurité arrivent au rythme de la publication des failles, pas au rythme de vos disponibilités. Une plateforme déclarative permet de les appliquer en quelques minutes ; une plateforme bricolée transforme chaque correctif en négociation interne.

C'est précisément sur ce poste que l'outillage agentique change le rapport de forces. Le travail de veille, de lecture des notes de version, de préparation du changement et de vérification après coup est répétitif, exigeant et faiblement créatif : c'est le profil idéal pour être déchargé sur un agent, sous supervision, avec le même canal GitOps tracé et réversible que le reste.

Qui répond à trois heures du matin

C'est la question qui reste, et celle que les articles sur l'infrastructure évitent soigneusement. Vous pouvez avoir la plus belle plateforme du monde : à un moment, quelque chose casse la nuit, et il faut quelqu'un.

L'astreinte est un coût que presque personne ne budgète honnêtement. Pas seulement en euros — en sommeil, en motivation, et en turnover chez les gens à qui on la confie. Dans une équipe de cinq développeurs, une rotation d'astreinte sérieuse est une charge que la plupart des startups ne peuvent tout simplement pas absorber.

Depuis un peu plus d'un an, je fais tourner sur ma propre infrastructure une astreinte tenue par un agent IA autonome : il reçoit l'alerte, diagnostique, et applique un correctif par le canal GitOps normal — donc revu, tracé, réversible. Sur les dix premiers jours, trois incidents réels ont été traités pour une dizaine de dollars d'inférence au total. Même en multipliant par dix pour une infrastructure plus agitée, on reste deux ordres de grandeur sous le coût d'une astreinte humaine.

Je détaille le dispositif, ses garde-fous et les trois incidents dans J'ai confié mon astreinte SRE à un agent IA autonome. Les limites y sont posées aussi clairement que les résultats, et elles comptent : ce dispositif ne remplace pas une équipe SRE pour un service réglementé avec un engagement 24/7. Il traite le trivial et le critique-clair, et escalade tout le reste. Ce qui touche au niveau système ou matériel reste volontairement hors de son périmètre. Les premières exécutions se font en supervision, comme on accompagnerait une nouvelle recrue.

Ce qui le distingue d'un script d'auto-remédiation classique, c'est qu'il raisonne sur des situations jamais vues — mais dans un espace d'action borné où sa pire erreur possible reste réversible. L'enclos est technique, pas déclaratif. C'est toute la différence entre un garde-fou et une bonne intention.

Souveraineté : quand l'hébergement devient un argument commercial

Ce sujet a longtemps été une préoccupation de juriste. Il est devenu, ces deux dernières années, un argument de vente — et parfois une condition d'accès à un marché.

Trois situations le rendent concret. Un appel d'offres public ou parapublic qui exige un hébergement européen. Un client grand compte dont le service juridique bloque sur le transfert de données hors de l'Union. Un secteur — santé, éducation, secteur public — où la question sera posée systématiquement, quelle que soit la qualité de votre produit.

L'intérêt de la démarche décrite dans ce guide, c'est qu'elle règle la question par construction plutôt que par déclaration. Des serveurs dédiés chez un hébergeur européen, une plateforme dont vous maîtrisez l'intégralité de la configuration, et des données qui ne quittent jamais ces machines : la réponse à « où sont nos données » devient factuelle et vérifiable, pas contractuelle. C'est très différent d'une case cochée dans les conditions générales d'un fournisseur.

Un mot d'honnêteté, cependant : la souveraineté ne se réduit pas à la localisation des serveurs. Vos dépendances comptent aussi — l'outil d'analytique, le service d'envoi de mails, la brique d'authentification, le fournisseur de modèles d'IA. Une infrastructure hébergée en France qui expédie ses journaux applicatifs vers un service américain n'est pas souveraine, elle est décorée. L'audit utile est celui des flux sortants, pas celui du contrat d'hébergement.

Pour la plupart des équipes, ce n'est pas le premier motif de migration. C'est en revanche un bénéfice secondaire qui devient décisif au moment où un gros client pose la question — et à ce moment-là, il est trop tard pour l'obtenir en trois semaines.

Ce que ça coûte vraiment

Mettons les chiffres côte à côte, parce que la comparaison est rarement faite honnêtement.

Le scénario « équipe » : un SRE senior en France, charges comprises, représente un coût annuel à six chiffres. Ajoutez le délai de recrutement — rarement moins de trois mois pour un bon profil — et le risque qu'il parte au bout d'un an s'il s'ennuie.

Le scénario « socle » : une plateforme bare-metal orchestrée à environ cent euros mensuels d'hébergement, une dizaine d'heures de travail humain pour la monter si la compétence est là, et une astreinte automatisée à quelques dizaines de dollars par mois. La compétence, elle, se loue au moment où on en a besoin plutôt que de s'embaucher à plein temps.

Le second scénario n'est pas universellement meilleur. Il est meilleur dans une fenêtre précise : quand votre charge est prévisible, que votre besoin de fiabilité est réel mais pas réglementé, et que vous n'avez pas le volume d'incidents qui justifie un poste. Cette fenêtre couvre, à vue de nez, la grande majorité des startups entre la levée d'amorçage et la série B.

Hors de cette fenêtre, recrutez. Un service de santé sous obligation réglementaire, une plateforme de paiement, un produit avec un engagement contractuel de disponibilité : ces contextes demandent une équipe, et aucun outillage n'y change quoi que ce soit.

Les pièges à éviter

Confondre « ça tourne » et « c'est en production ». Un service accessible sur internet n'est pas une production. Une production, c'est un service dont on sait comment il se comporte quand il tombe, et dont quelqu'un a déjà vérifié qu'il se relève.

Croire ses sauvegardes sur parole. Voir plus haut. Sept semaines sans un octet sauvegardé, avec des logs verts. Restaurez pour de vrai, régulièrement, et notez la date de la dernière restauration réussie quelque part de visible.

Sur-dimensionner pour se rassurer. Multiplier les régions, les réplications et les services managés « au cas où » revient à payer une assurance contre des risques que vous n'avez pas encore. Commencez par survivre à la perte d'une machine ; c'est déjà 90 % du bénéfice.

Automatiser avant d'avoir compris. Une procédure qu'on n'a pas exécutée manuellement au moins trois fois n'est pas mûre pour l'automatisation.

Prendre l'IA pour un substitut d'expertise. C'est le piège du moment, et le plus coûteux. L'IA agentique permet à un expert d'aller dix fois plus vite. Elle permet à un non-expert de produire dix fois plus vite quelque chose qui ne tiendra pas. Le facteur multiplicatif s'applique à ce que vous savez déjà.

Par où commencer

Si vous lisez ce guide parce que la question du SRE se pose chez vous, voici l'ordre que je recommande.

D'abord, objectivez votre situation avec les cinq exigences plus haut : haute disponibilité, sauvegardes testées, observabilité, état déclaré, données opérées. Cochez honnêtement. Le résultat vous dira si votre problème est un problème de recrutement ou un problème de socle.

Ensuite, traitez le socle avant le poste. Une infrastructure ennuyeuse rend le recrutement d'un SRE moins urgent, et le rend surtout plus réussi le jour où il arrive : il travaillera sur la fiabilité au lieu de rattraper l'existant.

Enfin, louez la compétence pour le montage, gardez-la en interne pour l'exploitation. Monter une plateforme est un projet borné ; l'exploiter est un régime permanent. Ce sont deux besoins différents, qui n'appellent pas le même engagement.