Toute plateforme qui porte du chiffre d’affaires finit par poser une question : qui est responsable lorsqu’elle tombe à trois heures du matin ? La plupart des entreprises y répondent par défaut plutôt que par décision. Les ingénieurs qui ont construit le système le maintiennent en marche, une astreinte se forme de manière informelle, et l’exploitation devient une charge que l’équipe produit absorbe. Cet arrangement tient — jusqu’au jour où il devient coûteux.
Cet article compare les deux réponses délibérées : constituer une équipe d’exploitation interne, ou contracter des services d’infogérance sous SLA. Nous vendons la seconde ; lisez donc ce qui suit en le sachant. Nous avons voulu une comparaison honnête — il existe des cas où l’interne est clairement le bon choix, et nous commençons par ceux-là.
Quand l’équipe interne est le bon choix
Si l’exploitation fait partie de ce que vous vendez, gardez-la. Une entreprise dont le produit est l’infrastructure — plateforme d’hébergement, processeur de paiements, système de trading — se différencie par sa capacité opérationnelle, et l’externaliser reviendrait à externaliser un avantage concurrentiel. Le même raisonnement vaut lorsque le savoir opérationnel est réellement propriétaire : matériel spécialisé, contraintes de latence strictes, ou environnements réglementés où le contrôle quotidien doit rester en interne.
L’interne l’emporte aussi lorsque vous avez la taille pour le faire correctement. Une équipe de huit ingénieurs seniors ou plus peut tenir une rotation soutenable, construire son propre outillage et conserver la connaissance des incidents dans l’entreprise. Si vous pouvez recruter et retenir ces profils, une équipe interne vous offre la boucle la plus courte possible entre les décisions produit et la réalité opérationnelle. Aucun contrat n’égale cela.
Le vrai test n’est pas de savoir si vous pourriez constituer une équipe d’exploitation. C’est de savoir si l’argent et l’attention de direction qu’elle consomme produiraient davantage de valeur là que sur votre feuille de route produit.
Le coût réel d’une astreinte interne
Le coût visible, c’est l’effectif. Une couverture 24/7 soutenable exige au minimum cinq à six ingénieurs ; en dessous, chacun est d’astreinte une semaine sur deux ou trois — une lettre de démission à retardement. Aux salaires seniors d’Europe de l’Ouest, cette rotation représente un engagement annuel à six chiffres avant la première ligne de code produit.
Les coûts moins visibles s’accumulent autour d’elle :
Rien de tout cela n’apparaît sur une ligne budgétaire intitulée « exploitation ». Ces coûts se dispersent entre les salaires, les honoraires de recrutement, les versions retardées et les entretiens de départ — et c’est précisément pour cela qu’on les sous-estime.
- Primes d’astreinte, récupérations et planification autour des congés et des arrêts maladie
- Outillage de monitoring, d’alerte et de gestion des incidents, plus le temps de le maintenir
- Productivité diurne perdue en sommeil interrompu et en changements de contexte
- Attrition : des ingénieurs recrutés pour construire un produit supportent mal les nuits passées à éteindre des incendies, et ils partent
- Re-recrutement : remplacer un ingénieur d’exploitation senior prend des mois, et la connaissance des incidents part avec lui
Ce qu’un SLA transfère réellement
Un contrat d’infogérance transfère un ensemble défini d’obligations, par écrit. Dans nos contrats, cela signifie un monitoring 24/7, quatre niveaux de sévérité (P1–P4) avec des délais de réponse et de rétablissement propres à chaque niveau, l’application des correctifs de sécurité, le maintien de la chaîne CI/CD et la correction des bugs — avec des conséquences financières pour nous lorsque nous manquons un objectif. Nous répondons aux incidents P1 en moins d’une heure parce que le contrat l’exige, pas parce que quelqu’un se trouve être éveillé.
L’effet économique, c’est la conversion d’un coût interne imprévisible — effectifs, outillage, attrition, escalades à trois heures du matin — en un montant mensuel fixe au périmètre défini. Le calcul des rotations, la discipline d’alerte et le processus de post-mortem deviennent le problème du prestataire. C’est un transfert de responsabilité au sens précis du terme : des obligations mesurables, assorties de pénalités, portées par un acteur dont l’activité dépend de leur respect.
Ce qu’un SLA ne transfère pas
La responsabilité vis-à-vis de vos clients reste la vôtre. Quand votre plateforme est indisponible, ce sont vos clients qui vous appellent, pas votre prestataire. Un SLA peut garantir la réponse et le rétablissement ; il ne prend pas vos décisions d’architecture à votre place, et il n’absorbe pas votre position réglementaire : au titre du RGPD, vous restez en général responsable de traitement, le prestataire agissant comme sous-traitant dans le cadre d’un accord de traitement des données.
Un contrat sérieux exige aussi des choses de votre côté. Le prestataire a besoin d’un accès réel, d’une documentation à jour, d’un interlocuteur technique désigné et de l’autorité nécessaire pour modifier ce qu’il exploite. Un SLA portant sur une infrastructure que personne n’a le droit de toucher relève du théâtre. Si votre organisation ne peut pas déléguer cette autorité, le contrat sous-performera — et cet échec sera autant le vôtre que celui du prestataire.
Critères de décision
Il n’existe pas de formule, mais cinq questions tranchent la plupart des cas :
Si l’exploitation est un facteur de différenciation et que vous avez la taille, construisez en interne. Si c’est une dépendance et que les réponses honnêtes aux autres questions sont inconfortables, transférez-la — dans le cadre d’un contrat qui rend chaque obligation explicite.
- Taille : pouvez-vous mobiliser cinq à six ingénieurs sur une rotation sans affamer la feuille de route ?
- Différenciation : vos clients vous paient-ils pour votre capacité opérationnelle, ou s’agit-il d’une dépendance ?
- Coût de l’indisponibilité : que coûte une heure d’interruption non planifiée, en chiffre d’affaires et en pénalités contractuelles ?
- Réalité du recrutement : pouvez-vous attirer et retenir des ingénieurs d’exploitation seniors sur votre marché cette année ?
- Vélocité : quelle part de la semaine de vos ingénieurs disparaît aujourd’hui dans la gestion d’urgences ?
Où la frontière se place le plus souvent
La plupart des entreprises avec lesquelles nous travaillons aboutissent à un partage des rôles plutôt qu’à un choix en bloc. Leurs ingénieurs gardent le produit, les orientations d’architecture et les décisions qui différencient l’entreprise. Le prestataire prend en charge le run : monitoring, réponse aux incidents, correctifs et discipline de déploiement, le tout encadré par le SLA. La frontière est écrite, revue régulièrement et ajustable à mesure que la plateforme évolue.
Quelle que soit votre décision, prenez-la délibérément — et gardez-la réversible. Exigez de tout prestataire, nous compris, une documentation traitée comme un livrable, une clause de sortie et une procédure de réversibilité définie. Le seul modèle que nous déconseillons est le choix par défaut : une exploitation absorbée informellement par l’équipe produit, sans budget ni responsable. C’est l’option la plus chère de toutes, et ses coûts sont les plus difficiles à voir.