Quand l'optimisation carbone fait tomber un service critique : un sinistre décortiqué

Prenons un cas réaliste. Un consultant GreenOps est missionné par une fintech pour réduire l'empreinte carbone de son infrastructure cloud. Après audit, il identifie une cible évidente : un cluster de calcul surdimensionné qui tourne en permanence à 15 % de charge moyenne. La recommandation tombe sous le sens : réduire le nombre d'instances, activer l'autoscaling agressif et passer certaines machines sur des familles d'instances plus sobres. Sur le papier, c'est une réduction de 40 % de la consommation et une économie significative.

La reco est appliquée un mardi. Tout fonctionne. Jusqu'au vendredi soir, jour de pic de transactions, où l'autoscaling ne monte pas assez vite : le service de paiement sature, la latence explose, puis le service tombe. Neuf heures d'indisponibilité partielle sur le créneau le plus rentable de la semaine.

L'empreinte carbone et la résilience tirent souvent sur la même corde : la marge de capacité. Réduire l'une sans modéliser l'autre, c'est transformer une optimisation en pari sur la charge.

La sobriété cloud repose en grande partie sur l'élimination du gaspillage : machines sous-utilisées, environnements oubliés, sur-provisionnement « au cas où ». Le problème, c'est que ce sur-provisionnement est précisément ce qui absorbe les pics imprévus et les défaillances partielles.

Trois leviers GreenOps classiques sont aussi des leviers de risque :

• Le rightsizing. Ajuster la taille des instances à la charge réelle supprime le coussin de sécurité qui encaissait les rafales.
• L'autoscaling agressif. Démarrer moins de machines par défaut suppose que la montée en charge sera assez rapide. Sous pic brutal, le délai de provisionnement devient le maillon faible.
• Le scale-to-zero et la mise en veille. Éteindre ce qui ne sert pas la nuit est vertueux, sauf si un batch critique ou une astreinte en dépend.

Aucun de ces leviers n'est dangereux en soi. Ils le deviennent quand la recommandation n'intègre pas le profil de charge réel, les pics saisonniers et les exigences de disponibilité du service. C'est exactement le terrain sur lequel une RC Pro de consultant est attendue : la conséquence d'un conseil technique qui cause un dommage au client.

L'erreur classique consiste à raisonner « ma mission valait 8 000 €, mon exposition est plafonnée à ce montant ». Faux. Le préjudice subi par le client est sans rapport avec vos honoraires. Voici un ordre de grandeur réaliste pour neuf heures d'indisponibilité d'un service de paiement :

On atteint rapidement plusieurs dizaines de milliers d'euros. Le point central : il s'agit de dommages immatériels non consécutifs (perte d'exploitation sans dommage matériel préalable). Beaucoup de contrats RC Pro génériques les excluent ou les sous-plafonnent. C'est la première clause à vérifier.

Le réflexe défensif du consultant est de dire : « j'ai recommandé, c'est le client qui a décidé d'appliquer ». C'est partiellement vrai et largement insuffisant. La validation du client ne purge pas votre responsabilité si l'on vous reproche un manquement au devoir de conseil ou une faute technique d'analyse.

Concrètement, on vous demandera :

• Avez-vous modélisé les pics de charge avant de recommander la réduction de capacité ?
• Avez-vous explicitement alerté sur le risque de disponibilité et proposé des garde-fous (seuils d'autoscaling, capacité réservée, tests de charge) ?
• Avez-vous recommandé une phase de test en pré-production avant la mise en production un jour de faible trafic ?

Si la réponse est non, la validation du client ne vous protège pas : un professionnel est tenu d'éclairer un client même averti sur les risques de sa recommandation. C'est précisément la zone grise que couvre la responsabilité civile professionnelle : la faute de conseil et ses conséquences financières, frais de défense inclus.

Dans ce type de sinistre, la preuve de votre diligence fait toute la différence entre une responsabilité pleine et une responsabilité partagée. Quatre pièces pèsent lourd :

1. Le rapport d'audit avec hypothèses de charge. Il montre que vous avez raisonné sur des données, pas à l'aveugle.
2. La trace écrite des risques signalés. Un mail, une slide, une clause de rapport alertant sur le risque de disponibilité déplace nettement la répartition de responsabilité.
3. La recommandation de tester avant production. Si le client a court-circuité la phase de test que vous préconisiez, c'est documenté.
4. Le périmètre contractuel de la mission. Un cadrage clair (audit et reco, hors mise en production) délimite votre exposition.

Ces éléments ne suppriment pas le sinistre, mais ils déterminent si vous payez tout, une part, ou si la responsabilité bascule vers le client qui a négligé vos préconisations. C'est cette répartition que votre assureur défendra. Pour cadrer l'ensemble de votre exposition selon votre activité réelle, partez de votre fiche assurance pour consultant GreenOps cloud.