Quand votre IDP tombe : qui paie le downtime de toute l'entreprise ?

Une Internal Developer Platform (IDP) n'est pas un outil de plus dans la stack. C'est la couche par laquelle passent tous les déploiements de l'entreprise : portails Backstage, golden paths CI/CD, templates Terraform, abstractions au-dessus de Kubernetes, observabilité intégrée. Quand vous opérez cette plateforme, vous ne servez pas une équipe, vous servez l'intégralité de l'organisation produit.

Cette centralisation est précisément ce qui crée de la valeur — standardisation, réduction de la charge cognitive des squads, accélération du time-to-market. Mais elle crée aussi une concentration de risque inédite pour un métier du numérique. Un développeur qui casse son propre service impacte son équipe. Un ingénieur plateforme qui casse l'IDP impacte chaque squad qui en dépend, simultanément.

Les juristes parlent de point de défaillance unique ; les SRE parlent de blast radius. Les deux notions convergent vers la même réalité assurantielle : un seul geste technique peut générer un préjudice diffus sur des dizaines de projets en parallèle. Cette concentration est rarement comprise au moment de souscrire un contrat, parce qu'elle ne ressemble à aucun risque industriel classique : il n'y a ni stock, ni machine, ni chantier, seulement un effet de levier logiciel. C'est un changement de nature, pas seulement d'échelle. Là où un incident applicatif classique reste circonscrit à un périmètre fonctionnel, un incident plateforme se propage par construction, parce que la plateforme est conçue pour être le dénominateur commun de tous les delivery.

Cette singularité explique pourquoi les contrats d'assurance génériques pour développeurs ou prestataires informatiques sont rarement calibrés pour le platform engineering. Ils raisonnent en livrable unique remis à un client unique. Or votre livrable — la plateforme — est consommé en continu, par de multiples équipes internes, à chaque déploiement. La question assurantielle n'est plus « qu'arrive-t-il si je livre un produit défectueux à un client », mais « qu'arrive-t-il si l'outil dont dépend toute l'entreprise s'arrête à cause de moi ». La réponse mobilise des garanties très spécifiques.

Quand votre plateforme est indisponible, rien ne brûle, rien ne se casse physiquement. Pourtant le préjudice est bien réel : les équipes ne peuvent plus livrer, les correctifs urgents restent bloqués, une fenêtre de mise en production critique est manquée. On parle de dommage immatériel.

Le droit distingue deux familles :

• Dommage immatériel consécutif : il découle d'un dommage matériel ou corporel préalable (rare en platform engineering).
• Dommage immatériel non consécutif : il survient sans aucun support matériel — exactement le cas d'une IDP indisponible qui gèle les déploiements.

C'est un point critique : beaucoup de RC Pro standard excluent ou plafonnent fortement le dommage immatériel non consécutif. Pour un ingénieur plateforme, c'est pourtant le risque numéro un. Une couverture qui ne mentionne pas explicitement cette garantie laisse un trou béant face au scénario le plus probable.

Pourquoi cette exclusion est-elle si répandue ? Parce que l'immatériel pur est difficile à borner pour un assureur : il n'y a pas de bien à expertiser, le préjudice se mesure en perte d'exploitation et en manque à gagner, des montants potentiellement élevés et diffus. Les contrats grand public préfèrent donc l'écarter. À l'inverse, une RC Pro pensée pour les métiers du numérique l'intègre explicitement, car elle sait que c'est le sinistre type de ces activités. Avant toute souscription, la première vérification d'un ingénieur plateforme devrait donc porter sur cette ligne précise des conditions générales.

Concrètement, lorsqu'une IDP est indisponible, le préjudice se construit minute après minute : pipelines en attente, déploiements gelés, fenêtres de mise en production manquées. Aucun de ces éléments ne laisse de trace matérielle, mais chacun a un coût économique mesurable. C'est exactement le terrain de la garantie dommages immatériels non consécutifs, et c'est pourquoi son absence rend une couverture quasiment inopérante pour ce métier.

La responsabilité de l'ingénieur plateforme repose presque toujours sur une obligation de moyens, pas de résultat : vous vous engagez à mettre en œuvre les diligences d'un professionnel compétent, pas à garantir un uptime absolu. C'est protecteur — mais cette protection s'effrite si le contrat impose des SLA chiffrés ou si une négligence caractérisée est démontrée (absence de tests sur un déploiement plateforme, rollback impossible, fenêtre de maintenance non communiquée).

La configuration contractuelle change tout :

• Salarié : votre employeur assume en principe les conséquences vis-à-vis des tiers, sauf faute détachable.
• Freelance ou via une ESN : vous êtes un prestataire, donc directement exposé. La scale-up cliente peut se retourner contre vous au titre de la responsabilité contractuelle.

Dans ce second cas, l'attestation de RC Pro n'est pas une formalité : elle est exigée à la signature, et son périmètre doit couvrir explicitement les activités de build et de maintien de produits internes. Une attestation libellée « développement logiciel » sans mention de l'opération de plateforme interne peut être contestée par l'assureur au moment du sinistre.

Un point souvent négligé : la frontière entre faute de service et faute détachable. Un salarié couvert par la responsabilité de son employeur perd ce bouclier si l'on démontre une faute détachable de ses fonctions — par exemple un contournement délibéré des procédures. C'est rare, mais cela explique pourquoi certains ingénieurs plateforme seniors, fortement exposés, choisissent une couverture personnelle complémentaire. Pour un freelance, la question ne se pose même pas : il est, par défaut, en première ligne pour toute réclamation du client final.

Pour comprendre l'enjeu, il faut raisonner en coût agrégé, pas en coût unitaire. Imaginons une scale-up de huit squads dont la plateforme reste indisponible une demi-journée à cause d'une mise à jour ratée du portail de déploiement.

Aucun de ces postes n'est couvert par une assurance multirisque classique : il n'y a ni bris de machine, ni dégât des eaux. Seule une RC Pro calibrée pour le préjudice immatériel répond à ce profil de sinistre.

La meilleure assurance reste la traçabilité. En cas de réclamation, votre défense reposera sur votre capacité à démontrer que vous avez agi en professionnel diligent :

1. Versionner et documenter chaque changement de la plateforme (golden paths, templates, modules).
2. Tester les déploiements plateforme en environnement de staging avant généralisation.
3. Garantir un rollback rapide et documenté pour chaque release de l'IDP.
4. Communiquer les fenêtres de maintenance aux squads consommatrices.
5. Formaliser le périmètre de votre prestation dans le contrat, SLA inclus.

Ces pratiques réduisent la probabilité du sinistre et renforcent votre position si un litige survient. La RC Pro prend alors le relais sur la part résiduelle de risque, avec sa garantie défense et recours pour porter le contentieux. Pour un ingénieur plateforme, c'est la combinaison rigueur technique plus couverture immatérielle qui sécurise réellement l'activité.