Un incident de production à 7 h 30 n’est jamais seulement un problème technique. Il bloque des commandes, ralentit une équipe support, abîme la confiance des clients et force les dirigeants à arbitrer dans l’urgence. Un prestataire run applicatif intervient précisément à cet endroit : là où une application doit continuer à fonctionner, être surveillée, corrigée et améliorée sans mettre l’activité en danger.
Pour une TPE ou une PME, le sujet n’est pas de reproduire l’organisation d’un grand groupe. Il est de savoir qui prend réellement la responsabilité opérationnelle quand le serveur sature, qu’un déploiement échoue, qu’une sauvegarde ne restaure pas ou qu’un ancien développeur a laissé un système sans documentation exploitable.
Le run applicatif n’est pas du simple support
Le run applicatif couvre l’exploitation quotidienne d’une application en production. Cela inclut son hébergement, ses déploiements, sa supervision, ses sauvegardes, la gestion des incidents, les correctifs de sécurité et une partie de l’évolution technique nécessaire pour conserver un système exploitable.
Cette définition paraît large parce que la réalité l’est. Une erreur applicative peut venir du code, d’une base de données, d’une dépendance externe, d’une configuration cloud, d’un certificat expiré ou d’un changement non documenté. Traiter le symptôme sans comprendre l’ensemble du système revient souvent à déplacer le problème de quelques jours.
Le support utilisateur répond à une question ponctuelle : « Pourquoi cet écran ne fonctionne-t-il pas ? » Le run, lui, doit répondre à une question plus exigeante : « Pourquoi ce type d’incident est-il possible, comment le détecter plus tôt et comment éviter qu’il revienne ? »
C’est pourquoi un bon intervenant run ne se contente pas d’ouvrir des tickets. Il observe, diagnostique, corrige, documente et priorise. Il sait aussi dire qu’une demande fonctionnelle doit attendre parce que l’environnement de production a besoin d’être assaini avant d’ajouter une couche de complexité.
Les signaux qui justifient un prestataire run applicatif
Le besoin apparaît rarement lors d’un plan stratégique proprement présenté. Il apparaît après un départ, un audit inquiétant, plusieurs incidents similaires ou un projet livré sans personne clairement responsable de l’exploitation.
Certains signaux doivent être pris au sérieux. Vos sauvegardes existent, mais personne n’a testé une restauration. Les déploiements dépendent d’une seule personne et d’une série de manipulations manuelles. Les alertes sont absentes ou trop nombreuses pour être utiles. L’équipe ne sait pas quelles versions tournent réellement en production. Les incidents se règlent dans Slack ou par téléphone, sans analyse après coup. Enfin, personne ne peut estimer le risque d’une mise à jour pourtant nécessaire.
Dans ces conditions, recruter immédiatement un profil interne senior n’est pas toujours la réponse la plus rapide. Le recrutement prend du temps, et un nouvel arrivant doit encore comprendre le code, l’infrastructure et les habitudes de l’entreprise. Un consultant expérimenté peut d’abord remettre de l’ordre, clarifier la dette opérationnelle et définir ce qui mérite ensuite d’être internalisé.
Cela ne signifie pas que l’externalisation est toujours préférable. Une société avec une plateforme très spécifique, une forte cadence de déploiement et une équipe produit importante aura souvent intérêt à construire une capacité interne. En revanche, pour une entreprise qui a un produit vivant mais pas de SRE, de DevOps senior ou de CTO à plein temps, un dispositif de run externalisé apporte une couverture immédiate et ciblée.
Ce que vous devez réellement acheter
Un contrat de run ne devrait pas être évalué sur le nombre d’heures disponibles ou sur une promesse vague de disponibilité. Vous achetez une capacité de jugement en production. Cette nuance fait toute la différence.
Avant de parler d’astreinte ou de forfait, un prestataire sérieux doit comprendre le périmètre : applications concernées, dépendances critiques, fournisseurs externes, environnements, volumes, fenêtres de maintenance, données sensibles et conséquences métier d’une indisponibilité. Un site vitrine, un outil interne de facturation et une plateforme SaaS qui gère des transactions ne demandent pas le même niveau de couverture.
Les livrables initiaux devraient être concrets. À minima, vous devez obtenir une cartographie de l’existant, une liste priorisée des risques, des accès propres et traçables, une procédure de déploiement, une politique de sauvegarde vérifiable et une base de connaissance pour les incidents récurrents. Sans ces éléments, vous ne sécurisez pas votre activité : vous déléguez simplement votre dépendance à une nouvelle personne.
Un bon dispositif clarifie aussi les limites. Le run couvre-t-il seulement les incidents ? Les petites évolutions sont-elles incluses ? Qui valide les changements fonctionnels ? Quel est le délai de prise en charge pendant les heures ouvrées ? Que se passe-t-il le soir, le week-end ou pendant les périodes commerciales critiques ? Les réponses dépendent du contexte, mais elles doivent être écrites avant le premier incident majeur.
Disponibilité ne veut pas dire intervention immédiate
Beaucoup de dirigeants demandent du « 24/7 » alors que leur besoin réel est différent. Si votre activité ne génère ni ventes ni opérations critiques la nuit, une supervision automatique avec une intervention le matin peut être raisonnable. À l’inverse, une interruption de quelques minutes peut coûter cher sur un service transactionnel ou une opération logistique.
Le bon niveau de service se calcule à partir de l’impact métier, pas d’une formule commerciale. Une promesse d’astreinte permanente est coûteuse. Elle n’a de sens que si les procédures, les accès, les alertes et le budget permettent de la tenir. Mieux vaut un engagement réaliste, mesuré et testé qu’un SLA décoratif que personne ne peut appliquer.
Comment évaluer un intervenant avant de lui confier la production
La première question est simple : lit-il votre code et vos configurations avant de proposer une solution ? Un prestataire qui recommande une refonte, une migration cloud ou l’ajout d’outils sans examiner l’existant travaille sur des hypothèses. En production, les hypothèses coûtent cher.
Demandez comment il aborde un incident. Une réponse mature parlera de collecte de faits, de limitation de l’impact, de communication, de correction, puis d’analyse de cause racine. Elle ne se résumera pas à « redémarrer le service » ou à ajouter un outil de monitoring. Redémarrer peut être nécessaire. Ce n’est pas une stratégie.
Regardez également sa capacité à travailler sur des systèmes imparfaits. Beaucoup d’environnements PME contiennent du code ancien, des scripts manuels, plusieurs comptes cloud, des secrets mal rangés et une documentation incomplète. Le bon profil ne dramatise pas cette situation et ne prétend pas la nettoyer en une semaine. Il établit un ordre de traitement : d’abord les risques de perte de données et d’arrêt, ensuite les fragilités de déploiement, puis la dette qui ralentit durablement les évolutions.
Enfin, évaluez la qualité des écrits. Après une intervention, vous devez pouvoir comprendre ce qui a été constaté, ce qui a été modifié, les risques résiduels et les décisions à prendre. Une recommandation exploitable indique une priorité, un impact, un effort estimé et un propriétaire. Un rapport rempli de généralités techniques ne vous aide pas à décider.
Le run commence par une reprise maîtrisée
Prendre en charge une application existante sans phase de reprise est imprudent. Avant d’accepter une responsabilité opérationnelle, le prestataire doit vérifier les accès, les mécanismes de restauration, les journaux, l’état des environnements, les dépendances et le processus de livraison.
Cette phase révèle souvent les problèmes que personne ne voulait regarder : comptes administrateurs partagés, sauvegardes incomplètes, certificats non suivis, coûts cloud non pilotés, instances oubliées ou déploiements impossibles à reproduire. Ce n’est pas un échec de l’audit. C’est précisément sa valeur.
Chez Rocket Services, la règle est volontairement simple : « Je lis votre code avant d’en écrire. » Elle vaut aussi pour le run. Une supervision utile dépend de ce que l’application fait réellement, pas seulement de l’état vert d’un serveur. Une API peut répondre correctement tout en produisant des données incohérentes. Une base peut être accessible tout en approchant un seuil de saturation. Les bons indicateurs sont ceux qui relient la santé technique à l’usage métier.
Faire du run un levier de décision
Un run applicatif bien conduit ne bloque pas l’évolution du produit. Il la rend moins risquée. Quand les déploiements sont reproductibles, les alertes pertinentes et les responsabilités claires, une équipe peut livrer avec davantage de contrôle. Elle passe moins de temps à réparer dans l’urgence et plus de temps à choisir ce qui mérite d’être construit.
Cela vaut aussi pour les projets IA. Ajouter un modèle, un fournisseur d’API ou un flux de données externe augmente les dépendances et les surfaces d’incident. Le sujet n’est pas d’ajouter de l’IA parce que le marché le demande. Il est de savoir qui surveille les coûts, les erreurs, les données envoyées et les conséquences d’une indisponibilité du fournisseur.
Le meilleur moment pour cadrer votre run n’est pas après la prochaine panne. Prenez un système critique, demandez qui peut restaurer ses données, déployer un correctif et expliquer son état actuel. Si la réponse n’est pas claire, vous avez déjà identifié le travail à faire.
Questions fréquentes
- Quelle est la différence entre le run applicatif et le support utilisateur ?
- Le support répond à une question ponctuelle (« Pourquoi cet écran ne fonctionne-t-il pas ? »), tandis que le run doit comprendre pourquoi ce type d'incident est possible, le détecter plus tôt et éviter qu'il revienne. Le run observe, diagnostique, corrige, documente et priorise ; il ne se contente pas d'ouvrir des tickets.
- Faut-il recruter un salarié senior ou faire appel à un prestataire run ?
- Le recrutement prend du temps et un nouvel arrivant doit d'abord comprendre le code et l'infrastructure. Un consultant expérimenté peut d'abord remettre de l'ordre et clarifier la dette opérationnelle. Pour une PME sans SRE ou DevOps senior à plein temps, un dispositif de run externalisé apporte une couverture immédiate et ciblée.
- Qu'est-ce qu'on devrait vraiment acheter dans un contrat de run ?
- Vous achetez une capacité de jugement en production. Les livrables initiaux doivent inclure une cartographie de l'existant, une liste priorisée des risques, des accès traçables, une procédure de déploiement, une politique de sauvegarde vérifiable et une base de connaissance pour les incidents récurrents.
- Est-ce que du 24/7 est toujours nécessaire ?
- Non. Si votre activité ne génère ni ventes ni opérations critiques la nuit, une supervision automatique avec intervention le matin peut être raisonnable. Le bon niveau de service se calcule à partir de l'impact métier, pas d'une formule commerciale. Mieux vaut un engagement réaliste et testé qu'un SLA décoratif.
- Comment vérifier qu'un prestataire run comprend réellement mon système ?
- Demandez-lui s'il lit votre code et vos configurations avant de proposer une solution. Regardez comment il aborde un incident : une réponse mature parlera de collecte de faits, limitation de l'impact, communication, correction et analyse de cause racine, pas seulement de redémarrage de service. Évaluez aussi la qualité de ses écrits : une recommandation exploitable indique une priorité, un impact, un effort estimé et un propriétaire.