Services
Infogérance & maintenance (SLA)
Nous assumons de bout en bout la responsabilité de la stabilité de votre plateforme, sous SLA contractuels à quatre niveaux de sévérité. Votre équipe se concentre sur le produit ; nous garantissons la plateforme.
Ce que nous prenons en charge
Une infogérance sous SLA, c’est un périmètre de responsabilité défini — pas une réserve de jours-homme.
- 01
Monitoring et alertes 24/7
Nous instrumentons votre infrastructure et vos applications, définissons avec vous les seuils d’alerte et les surveillons en continu. Les incidents sont détectés par nos soins, pas signalés par vos utilisateurs.
- 02
Astreinte et réponse aux incidents
Un ingénieur senior est d’astreinte en permanence. Lorsqu’une alerte se déclenche, nous intervenons dans le délai contractuel correspondant à sa sévérité — nuits, week-ends et jours fériés compris.
- 03
Délais de réponse garantis
Chaque incident est classé de P1 à P4, et chaque niveau de sévérité s’accompagne d’un délai de réponse contractuel et d’une cadence de communication. Vous savez comment nous réagirons avant même qu’un incident ne survienne.
- 04
Prise en charge des pipelines CI/CD
Nous assumons vos pipelines de build et de déploiement : nous les maintenons, les réparons lorsqu’ils cassent et gardons des mises en production reproductibles. Vos développeurs livrent leur code ; le pipeline est notre affaire.
- 05
Correctifs de sécurité
Nous suivons les bulletins de sécurité de vos systèmes d’exploitation, environnements d’exécution et dépendances, et appliquons les correctifs selon un calendrier défini. Les vulnérabilités critiques sont corrigées hors cycle.
- 06
Correction de bugs et maintenance
La maintenance corrective fait partie du contrat, pas des demandes d’évolution. Nous reproduisons, corrigeons et déployons, avec la même discipline de sévérité que pour les incidents d’infrastructure.
- 07
Sauvegardes et restauration
Nous gérons les calendriers de sauvegarde, la rétention et le chiffrement, et nous testons les restaurations à intervalles réguliers. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.
- 08
Rapport mensuel et revue
Chaque mois, vous recevez un rapport couvrant incidents, tenue des SLA, changements et risques, suivi d’une réunion de revue. Vous voyez précisément ce que vous payez.
Niveaux de sévérité et délais de réponse
Nos engagements sont gradués selon l’impact métier. Chaque incident se voit attribuer une sévérité à son ouverture, et cette sévérité détermine notre délai de réponse ainsi que la fréquence de nos points d’avancement.
P1≤ 1 h, 24/7
Production à l’arrêt ou impact métier critique ; aucune solution de contournement.
Toutes les 30 minutes
P2≤ 4 h, 24/7
Fonction majeure dégradée ou fort impact sur les performances ; une solution de contournement existe.
Toutes les 2 heures
P3≤ 1 jour ouvré
Dysfonctionnement limité à faible impact métier ; l’activité se poursuit normalement.
Quotidienne
P4≤ 2 jours ouvrés
Anomalie mineure, question ou demande d’amélioration sans impact opérationnel.
Hebdomadaire
Cette grille est fournie à titre indicatif ; les définitions de sévérité, les délais de réponse et les pénalités définitifs sont fixés contractuellement pour chaque engagement.
Comment se déroule la reprise
Transférer la responsabilité d’une plateforme est un exercice d’ingénierie, que nous conduisons en quatre étapes maîtrisées.
01
Audit
Nous cartographions votre infrastructure, votre code, vos pipelines, vos dépendances et l’historique des incidents. Le livrable est une évaluation écrite des risques et de ce qu’un SLA crédible peut couvrir dès le premier jour.
02
Plan de transition
Nous arrêtons ensemble le périmètre, les définitions de sévérité, les délais de réponse et les voies d’escalade, puis planifions la passation avec votre équipe ou votre prestataire actuel. Rien ne bouge tant que les responsabilités ne sont pas écrites.
03
Stabilisation
Nous mettons sous contrôle le monitoring, les alertes, les sauvegardes et les déploiements, et nous corrigeons les défauts qui rendraient le SLA intenable. Cette phase s’achève lorsque la plateforme est mesurablement stable.
04
Régime de croisière
Le SLA complet entre en vigueur : monitoring 24/7, astreinte, correctifs de sécurité et rapports. À partir de là, la stabilité de la plateforme est contractuellement notre problème — plus le vôtre.
Les outils que nous exploitons
Nous opérons des outils éprouvés et largement adoptés — et nous travaillons avec votre stack existante plutôt que d’imposer une migration.
Monitoring & alertes
- Grafana
- Prometheus
- Datadog
- Sentry
- PagerDuty
CI/CD & automatisation
- GitHub Actions
- GitLab CI
- Terraform
- Ansible
- Argo CD
Plateformes & environnements d’exécution
- AWS
- Azure
- Google Cloud
- Kubernetes
- Docker
- PostgreSQL
Ce qui change pour vous
L’objet du contrat est un transfert de responsabilité, et cela se mesure à la manière dont votre organisation emploie son temps.
Vos ingénieurs construisent le produit
Les tâches d’exploitation subies sortent de votre feuille de route. Vos développeurs ne portent plus l’astreinte et ne perdent plus de sprints à éteindre des incendies d’infrastructure.
Une gestion des incidents prévisible
Chaque incident suit le même parcours contractuel : classé, traité dans son délai, suivi à cadence fixe. Les pannes cessent d’être des crises improvisées.
Une plateforme maintenue à jour
Mises à jour de sécurité, montées de version des dépendances et tests de restauration suivent le calendrier prévu, parce qu’ils relèvent de nos obligations contractuelles — et non d’une tâche en concurrence avec vos développements produit.
Une responsabilité auditable
Les rapports mensuels documentent les incidents, la tenue des SLA et les changements. Vous disposez d’un interlocuteur responsable unique, preuves à l’appui, plutôt que d’un ensemble diffus d’obligations internes.
Questions fréquentes
01Combien de temps dure la reprise ?
Cela dépend de l’état de la plateforme. L’audit prend généralement quelques semaines ; la stabilisation peut durer de quelques semaines à quelques mois. Le SLA complet entre en vigueur dès que la plateforme atteint le niveau de référence convenu, et ce calendrier figure dans le plan de transition.
02Nos développeurs peuvent-ils continuer à travailler sur le produit ?
Oui — c’est précisément le fonctionnement prévu. Votre équipe continue de développer le produit pendant que nous assumons la plateforme : monitoring, déploiements, correctifs et réponse aux incidents. Nous définissons ensemble les interfaces — revues de code, fenêtres de déploiement, voies d’escalade — afin que chacun sache où se situe la responsabilité.
03Les conditions des SLA sont-elles négociables ?
Oui. La grille présentée sur cette page constitue notre point de départ standard. Les définitions de sévérité, les délais de réponse, les plages de couverture et les pénalités sont fixés contractuellement pour chaque engagement, en fonction des conclusions de l’audit et des besoins réels de votre activité.
04Où l’équipe est-elle basée, et comment gérez-vous le RGPD ?
Nos ingénieurs sont à Bucarest et travaillent avec une heure d’avance sur CET : nos horaires recouvrent donc presque entièrement ceux de Paris, Berlin et Amsterdam. L’astreinte est assurée 24/7. Nous opérons en conformité avec le RGPD, hébergeons les données dans l’UE lorsque leur résidence l’exige et signons un accord de traitement des données dans le cadre du contrat.
Parlons de vos opérations techniques
Un appel d’introduction de 30 minutes avec un ingénieur senior — sans script commercial, sans engagement. Nous écoutons, nous posons des questions, et nous vous disons honnêtement si nous pouvons vous aider.