Un lundi matin, le site e-commerce répond encore, mais les commandes ne remontent plus dans l’ERP. Personne n’a déployé volontairement de changement. Une tâche planifiée a expiré, un certificat approche de sa date limite, et les alertes n’étaient envoyées à personne. C’est précisément le terrain du run applicatif : maintenir un système vivant, utile et prévisible une fois qu’il est en production.
Le run n’est pas le temps restant entre deux projets. C’est un travail de responsabilité sur un service déjà utilisé par des clients, des équipes et parfois des partenaires. Lorsqu’il est traité comme une simple ligne de support, les incidents deviennent plus longs, les décisions plus risquées et la dette technique prend le contrôle du calendrier.
Le run applicatif ne se limite pas à corriger des bugs
Une application en production dépend de beaucoup plus que de son code. Elle dépend de ses serveurs, de sa base de données, de ses tâches asynchrones, de ses API tierces, de ses certificats, de ses sauvegardes et des personnes capables d’intervenir quand une alerte survient. Une panne est souvent le résultat d’une chaîne mal observée, pas d’une erreur unique.
Le périmètre du run applicatif couvre donc la supervision, le traitement des incidents, les correctifs, les mises à jour de sécurité, la gestion des accès, les déploiements, les sauvegardes et la vérification qu’elles sont restaurables. Il inclut aussi un travail moins visible mais déterminant : documenter ce qui a été constaté, ce qui a été changé et ce qui reste fragile.
Pour une PME, l’objectif n’est pas de reproduire l’organisation d’un grand groupe avec une équipe d’astreinte complète. Il est de connaître les risques réels, de prioriser les protections utiles et de ne pas dépendre d’une seule personne qui connaît tout de mémoire.
Ce qui doit être sous contrôle en production
Un bon run commence par une lecture factuelle du système existant. Quelles applications tournent ? Où sont hébergées les données ? Quelles dépendances externes peuvent bloquer le métier ? Qui possède les accès d’administration ? Sans ces réponses, une intervention urgente se transforme vite en enquête improvisée.
Observer le service, pas seulement les serveurs
Un serveur disponible ne signifie pas que l’application fonctionne. Une page peut charger alors que le paiement échoue, que les emails transactionnels ne partent plus ou que la synchronisation comptable est arrêtée. La supervision doit suivre les signaux qui comptent pour l’activité : taux d’erreur, temps de réponse, saturation de ressources, échecs de jobs, files d’attente, disponibilité des intégrations et volumes anormaux.
Toutes les alertes ne se valent pas. Une alerte qui sonne chaque nuit sans action utile finit ignorée. À l’inverse, l’absence d’alerte sur une sauvegarde défaillante ou une file de traitement bloquée crée de faux sentiments de sécurité. Il faut définir un seuil, un destinataire et une action attendue pour chaque signal critique.
Sauvegarder, puis restaurer
La sauvegarde est souvent présente dans un contrat d’hébergement, mais rarement vérifiée. Or une sauvegarde inutilisable ne protège rien. Il faut savoir quelles données sont incluses, à quelle fréquence elles sont copiées, combien de temps elles sont conservées, où elles sont stockées et combien de temps prendra une restauration.
Le bon test est simple : peut-on restaurer une base de données et remettre l’application dans un état exploitable sans dépendre d’un ancien prestataire ? La réponse peut être nuancée selon le budget et les objectifs de reprise, mais elle ne doit jamais rester théorique.
Déployer sans jouer à quitte ou double
Les déploiements sont une source classique d’incidents évitables. Une migration de base non réversible, une variable d’environnement oubliée ou une dépendance mise à jour trop vite peuvent dégrader le service en quelques minutes. Le remède n’est pas forcément une chaîne DevOps complexe. C’est d’abord une procédure reproductible, des validations avant mise en ligne et une possibilité claire de retour arrière.
Sur un produit à faible fréquence de changement, un processus simple et bien suivi est souvent préférable à une automatisation fragile. Sur un SaaS qui déploie plusieurs fois par semaine, l’automatisation devient nécessaire, à condition qu’elle soit comprise et maintenue. Le niveau de sophistication dépend du rythme de l’activité, pas de la mode du moment.
Le run applicatif est aussi un cadre de décision
La difficulté n’est pas seulement technique. À chaque incident, il faut décider s’il convient de rétablir immédiatement, de contourner le problème, de corriger la cause ou de suspendre une fonctionnalité. Ces choix ont des effets sur les clients, les équipes et les coûts.
Prenons une intégration avec un outil de facturation. Si elle tombe, la priorité peut être de préserver les commandes et de mettre les données en attente, plutôt que de réparer l’intégration dans l’heure. Mais ce choix suppose que les données soient traçables et rejouables. Sans mécanisme de reprise, une solution temporaire devient vite une perte d’information.
C’est pourquoi chaque incident significatif mérite une analyse courte et écrite : impact observé, chronologie, cause probable, mesure immédiate, action préventive et responsable désigné. Pas un rapport de cinquante pages. Quelques lignes précises suffisent pour éviter de revoir le même incident trois mois plus tard.
Les signes qu’un système manque de pilotage
Certaines situations reviennent dans les environnements délaissés : les accès de production sont partagés dans une messagerie, personne ne sait qui paie l’hébergement, les mises à jour sont reportées indéfiniment, et les anomalies sont découvertes par les utilisateurs. Une application peut continuer à fonctionner ainsi pendant longtemps. Cela ne veut pas dire qu’elle est maîtrisée.
Le signal le plus coûteux est souvent l’absence de visibilité. Quand une direction ne peut pas répondre à des questions simples - où sont les sauvegardes, quel est le dernier déploiement, quelles dépendances expirent bientôt, qui intervient en cas de panne - elle subit son système au lieu de le piloter.
Un audit initial permet généralement de remettre de l’ordre rapidement. Il établit l’architecture réelle, les comptes et accès, les flux de données, les alertes existantes, les procédures de déploiement et les risques prioritaires. Le livrable doit être actionnable : ce qui est critique maintenant, ce qui peut attendre, le coût et l’effet attendu de chaque correction.
Une méthode réaliste pour les TPE et PME
Un dispositif de run utile ne commence pas par l’achat d’outils. Il commence par la réduction des angles morts. Dans beaucoup de cas, les premières semaines doivent servir à récupérer les accès, cartographier les services, tester les sauvegardes et mettre en place quelques alertes pertinentes.
Ensuite vient la stabilisation : corriger les échecs récurrents, supprimer les tâches manuelles à risque, documenter les opérations fréquentes et sécuriser les déploiements. Les évolutions fonctionnelles peuvent reprendre dans de meilleures conditions, car l’équipe sait enfin ce qu’elle modifie et comment elle reviendra en arrière si nécessaire.
Rocket Services intervient dans cette logique : lire le code et l’infrastructure existants avant de proposer des changements, puis produire des décisions et des actions vérifiables. Le but n’est pas de maintenir artificiellement une dépendance au prestataire. Le but est de remettre la production dans un état où les responsabilités, les risques et les prochaines étapes sont clairs.
L’IA peut ajouter des composants, des flux de données et des dépendances à surveiller. Elle ne remplace ni la gestion des secrets, ni la traçabilité, ni un plan de reprise. Ajouter une brique IA à une application instable ne corrige pas ses fondations.
Un run bien tenu est rarement spectaculaire. Les clients ne remarquent pas les incidents qui n’arrivent pas, les restaurations qui ont été testées ou les déploiements qui se passent normalement. C’est pourtant là que se construit la confiance opérationnelle : dans une production tenue avec méthode, documentée sans excès et corrigée avant que le problème ne devienne une crise.
Questions fréquentes
- Comment savoir si mes sauvegardes fonctionnent vraiment ?
- Testez une restauration complète : pouvez-vous restaurer votre base de données et remettre l'application en état de fonctionner sans dépendre d'un ancien prestataire ? Si vous ne pouvez pas répondre à cette question concrètement, vos sauvegardes ne vous protègent pas.
- Qu'est-ce qu'on doit surveiller en production au-delà de la disponibilité des serveurs ?
- Suivez les signaux métier : taux d'erreur, temps de réponse, saturation des ressources, échecs de jobs, files d'attente, disponibilité des intégrations et volumes anormaux. Un serveur disponible ne signifie pas que l'application fonctionne — le paiement peut échouer, les emails transactionnels peuvent ne pas partir, ou la synchronisation comptable peut être arrêtée.
- Faut-il automatiser tous les déploiements ?
- Cela dépend du rythme de l'activité. Sur un produit qui change peu, un processus simple et bien suivi est souvent préférable à une automatisation fragile. Sur un SaaS qui déploie plusieurs fois par semaine, l'automatisation devient nécessaire, à condition qu'elle soit comprise et maintenue.
- Que faire quand une intégration critique tombe en panne ?
- Il faut décider rapidement : rétablir immédiatement, contourner le problème, corriger la cause ou suspendre la fonctionnalité. Par exemple, si une facturation tombe, il peut être mieux de préserver les commandes et mettre les données en attente plutôt que de réparer l'intégration dans l'heure — mais cela suppose que les données soient traçables et rejouables.
- Par où commencer si mon système n'a pas de pilotage clair ?
- Commencez par récupérer les accès, cartographier les services, tester les sauvegardes et mettre en place quelques alertes pertinentes. Un audit initial permet généralement de remettre de l'ordre rapidement en établissant l'architecture réelle, les comptes, les flux de données et les risques prioritaires.