Service · Exploitation (Run) · Engagement annuel
Un Run dont vous restez maître.
Pas un Run qui vous dépossède.
Opération 24/7/365 de vos plateformes cloud, data, sécurité et workplace. SLA négociés en amont, équipe SRE dédiée, astreinte, runbooks tenus à jour, plan de réversibilité testé. Le run sans rupture, sans dilution de responsabilité.
Quand vous voulez un Run qui tient, sans hypothéquer votre liberté.
SLA non tenu actuellement
Vos plateformes ne respectent pas les engagements pris vis-à-vis de votre métier ou de vos clients. Vous voulez un infogéreur qui assume, contractuellement, des indicateurs.
Équipe interne sous-dimensionnée
Une ou deux personnes portent le run, l'astreinte est tenue à bout de bras, le bus factor est à 1. Vous avez besoin d'une équipe SRE structurée, sans bâtir un service interne complet.
Run hérité, dépendant d'une seule personne
Le run actuel repose sur un sachant difficile à remplacer. Vous voulez documenter, redonder, professionnaliser — sans tout casser pendant la transition.
Fin de contrat infogérance
Votre infogéreur actuel ne convient plus (qualité, prix, dépendance). Vous cherchez une transition propre, avec un plan de réversibilité opposable.
Certification ou audit à venir
NIS2, DORA, ISO 27001, audit interne : votre run doit prouver son niveau de service, ses processus, sa documentation. Il faut un partenaire qui sait passer ces audits.
Cinq étapes, du « pourquoi » à la roadmap exécutable.
Une mission Run Nivura suit une séquence stricte : audit de transition, onboarding, run nominal, amélioration continue et réversibilité organisée. Tout est cadré dès le contrat.
Audit de transition
Onboarding
Run nominal
Opération 24/7/365 selon SLA contractuels, astreinte, gestion d’incidents, déploiements, patch management, supervision, rapports mensuels.
Amélioration continue
Réversibilité
Six livrables concrets, en sources éditables, signés.
Le Run produit des livrables récurrents — pas seulement un service. Vous savez à tout moment où vous en êtes, ce que ça vous coûte, et comment vous reprendriez la main si nécessaire.
Registre de service
Périmètre supporté en détail : composants, niveaux de criticité, RACI, contacts, plages de service. Document vivant, mis à jour à chaque évolution.
Runbooks d’exploitation
Procédures complètes (démarrage, arrêt, scaling, dépannage, escalade) pour chaque composant supporté. Lisibles par un opérationnel externe.
Dashboard SLI / SLO
Indicateurs de service publiés en temps réel (Grafana, Datadog, ou votre outil) : disponibilité, latence, taux d’erreur, MTTR. Accessibles à votre RSSI / DSI.
Rapport mensuel d’exploitation
Synthèse SLA, incidents, changements, capacité, coûts, recommandations. Présenté en comité de pilotage mensuel.
Plan d’amélioration trimestriel
Priorités d’amélioration (toil, sécurité, FinOps, qualité), engagements chiffrés, suivi des actions précédentes. Validé en COPIL.
Plan de réversibilité
Plan documenté pour transférer le run à vos équipes ou à un tiers en ≤ 6 mois. Testé annuellement (a minima sur dossier, idéalement sur un périmètre).
SLA, COPIL mensuel, réversibilité contractuelle — opacité bannie.
Le service Run est un engagement long. Pour qu’il reste sain, il doit être contractuellement transparent et techniquement réversible. Voici comment ça se passe.
Engagement : annuel reconductible
Contrat de 12 mois reconductible tacitement, dénonçable avec préavis raisonnable (3 mois). Nous préférons un client qui peut partir et qui choisit de rester.
Équipe : SRE dédiée + équipe d'astreinte
Un référent technique par compte client, une équipe SRE dédiée à votre périmètre (mêmes ingénieurs sur la durée), pool d'astreinte mutualisé entre clients. Tous basés à Monaco et en France.
Rythme : COPIL mensuel + comité opérationnel hebdo
Un comité opérationnel hebdomadaire (45 min) sur les sujets en cours, un comité de pilotage mensuel (1h30) avec votre sponsor — bilan SLA, incidents, plan d'amélioration.
Tarification : forfait par périmètre supporté
Forfait mensuel calé sur le périmètre supporté (composants × criticité × heures de service). Pas de facturation aux tickets — pas d'incitation perverse à fragmenter les incidents. Heures projet hors périmètre facturées en T&M capé.
Sortie : ≤ 3 mois, dossier complet
Le contrat inclut une clause de réversibilité opposable : sur demande, transfert organisé vers vos équipes ou un tiers, en moins de 3 mois, avec dossier complet et compagnonnage. Sans pénalité.
12 mois · SRE dédiée + astreinte 24/7
Run d’une plateforme cloud critique (production AWS multi-comptes ou plateforme M365 / EUC).
- Audit de transition signé en J+30
- Onboarding terminé en J+90
- Premier rapport mensuel à J+120
- Premier plan d’amélioration à J+180
- Plan de réversibilité testé à 12 mois
- Astreinte 24/7/365 dès J+90
- COPIL mensuel · comité opérationnel hebdo
Trois engagements qui changent le contrat d’infogérance.
L’infogérance classique fonctionne par opacité : plus le client est dans le flou, plus l’infogéreur est confortable. Notre modèle est l’inverse : visibilité totale, runbooks à jour côté client, plan de réversibilité testé. Vous savez à tout moment ce que nous faisons, et combien il en coûterait de partir.
Visibilité totale, dashboards partagés
Vous accédez aux mêmes outils que nous : monitoring, ticketing, dashboard SLI/SLO. Pas de couche d’intermédiation, pas de rapport résumé qui cache les pannes. La même donnée que celle sur laquelle nous opérons.
Runbooks à jour côté client, en continu
Les runbooks ne vivent pas dans nos outils internes. Ils vivent dans votre Confluence, votre wiki, votre dépôt Git — au choix. Mis à jour à chaque incident résolu et à chaque changement. Vous pouvez à tout moment imprimer un runbook et le faire jouer par un autre.
Hébergés et versionnés chez vous
Plan de réversibilité testé, opposable
La clause de réversibilité n’est pas un alinéa dormant : elle est testée chaque année, soit sur dossier, soit en simulation, soit sur un périmètre réel. Vous avez la preuve, contractuelle et opérationnelle, qu’on peut partir en moins de 3 mois.
Test annuel inclus dans le contrat
Exploitation × 5 piliers
Ce que ce service donne, concrètement, sur chacun de nos piliers.
Le service « Exploitation (Run) » se décline sur les 5 expertises Nivura. Voici, pour chacune, la promesse spécifique et les livrables type.
| Pilier | Question à laquelle nous répondons | Livrables spécifiques |
|---|---|---|
| Cloud | « Opérer mon socle AWS / Azure 24/7, en restant maître du code. » | SRE dédiée, astreinte, gestion incidents, patch management, supervision, FinOps continu, COPIL mensuel. |
| IA | « Opérer mes plateformes RAG / agents en production, avec garde-fous. » | Supervision LLM (latence, coûts, dérive), gestion des modèles, suivi qualité, sécurité données, runbooks IA. |
| Cybersécurité & Souveraineté | « Opérer mon SOC, mes outils de détection et mon dossier d’homologation dans le temps. » | Run SIEM/SOC managé, gestion vulnérabilités, suivi conformité, dossier homologation tenu vivant, audits PASSI accompagnés. |
| End User Computing | « Opérer mes WorkSpaces et mon AppStream comme un service interne — pas comme une dette. » | Image management, supervision sessions, patch automatisé, support N2/N3, FinOps EUC, runbook bascule. |
| Bureautique & Microsoft 365 | « Opérer M365, Intune, Defender, Purview — sans dépendre du goodwill du tenant admin. » | Pilotage Intune multi-OS, gestion identités, suivi sécurité Defender, conformité Purview, audits licences trimestriels. |
Les Run multi-piliers sont la norme : un même client confie souvent Cloud + Cyber + EUC à une seule équipe SRE. Le tarif global devient alors plus avantageux que la somme des engagements isolés.
Run de plateformes critiques — secteur public.
Reprise de l’exploitation d’un périmètre cloud + sécurité critique d’une administration, avec migration d’un infogéreur historique. Cas anonymisé.
Étude de cas — Exploitation (Run)
D’un run opaque dépendant d’un sachant unique à un service SRE structuré, audité, réversible.
Administration · Périmètre critique · 2023–2026
Le client devait sortir d’un infogéreur historique dont le run reposait sur des procédures non documentées. Nivura a conduit une transition de 12 semaines, repris l’astreinte, mis en place les runbooks, le dashboard SLI/SLO et le COPIL mensuel. Le contrat inclut une clause de réversibilité testée chaque année — la dernière simulation a montré une reprise possible en 4 mois.
Avant et après le Run — le cycle complet
Quatre autres façons de travailler avec Nivura, à enchaîner ou à mobiliser séparément.
Le service « Exploitation (Run) » est généralement précédé d’un Conseil ou d’un Build — mais nous reprenons aussi des plateformes existantes après audit de transition. À l’inverse, un Run Nivura n’empêche jamais de mobiliser nos autres services en parallèle (FinOps, Formation, Conseil).
Conseil & Stratégie
Cadrage, schéma directeur, business case et roadmap. Le « pourquoi » qui rend tout le reste possible — sans lock-in consultant.
Architecture & Build
Conception détaillée, revue d’architecture existante, industrialisation Terraform & GitOps, intégration continue, bascule maîtrisée. Du schéma directeur au socle qui tourne.
FinOps & Gouvernance
Optimisation continue des coûts cloud, gouvernance multi-comptes, contrôle des usages, conformité. La rigueur économique et la gouvernance sur la durée.
Formation & Enablement
Bootcamps AWS, formations IBM HashiCorp, parcours d’enablement et accompagnement à l’autonomie des équipes. La compétence qui reste, après que nous soyons partis.
Ce que nos clients nous demandent avant de signer.
Pouvez-vous reprendre un Run construit par un autre intégrateur ?
Oui, c’est même un cas fréquent. La condition : un audit de transition de 2 à 4 semaines pour évaluer la qualité de la documentation, la dette opérationnelle, et estimer le plan de remise à niveau. Si l’écart est important, nous proposons un sprint de remédiation avant le run nominal.
Quels SLA proposez-vous ?
Les SLA sont contractualisés au cas par cas selon la criticité métier — pas un catalogue figé. Niveaux de service typiques : 99,9 % à 99,95 % de disponibilité hors fenêtres planifiées, MTTR < 1h en heures ouvrées, < 2h hors heures ouvrées. Pénalités prévues. Indicateurs publiés en dashboard ouvert.
Tarification au ticket ou au forfait ?
Forfait mensuel calé sur le périmètre supporté. Pas de facturation à l’incident — c’est une incitation perverse à fragmenter les tickets et à ne pas résoudre les causes racines. Heures projet hors périmètre (évolutions majeures, expertises) en T&M capé, validées en COPIL.
Comment gérez-vous les astreintes ?
Pool d’astreinte 24/7/365 mutualisé entre clients, opéré par nos ingénieurs SRE (pas de sous-traitance). Numéro unique. Trois niveaux : N1 acquittement, N2 diagnostic, N3 expertise architecte. Procédure d’escalade documentée dans votre runbook.
Êtes-vous certifiés ISO 27001, HDS, etc. ?
ISO 27001 sur le périmètre opérationnel Nivura. Pour les périmètres clients soumis à HDS, hébergement souverain, ou homologation PSSI-E, nous opérons sur votre infrastructure (AWS, Azure, hébergeur souverain) et nous nous conformons à votre PSSI — pas à la nôtre.
Que se passe-t-il en cas de désaccord sur la qualité ?
COPIL mensuel comme premier lieu de résolution, plan d’action chiffré et daté en cas de manquement. Si le désaccord persiste, le contrat prévoit une médiation avant toute résiliation. Et si la résiliation est inévitable, la clause de réversibilité s’active immédiatement — sans pénalité.
Comment garantissez-vous l'absence de lock-in opérationnel ?
Quatre leviers concrets. (1) Tous les runbooks vivent chez vous. (2) Toute l’observabilité est partagée, vous y avez le même accès que nous. (3) Le plan de réversibilité est testé chaque année. (4) En cas de sortie, nous accompagnons la passation à vos frais réels — pas de pénalité de sortie.
Un Run à reprendre, à structurer, ou à externaliser proprement ? Faisons un audit de transition.
Atelier de cadrage initial gratuit (1h) suivi d’un audit de transition court — chiffré, daté, sans engagement. À l’issue, vous savez exactement ce qu’un Run Nivura coûterait, ce qu’il livrerait, et comment vous pourriez en sortir si besoin.