Quand un rule Pega Decisioning envoie la mauvaise offre à 4 millions de clients

Dans la plupart des métiers du développement, l'incident grave a une signature visible : l'application tombe, une page d'erreur s'affiche, le monitoring s'allume en rouge. Le consultant Pega qui travaille sur le Customer Decision Hub (CDH) vit dans un univers différent. Ici, le sinistre le plus coûteux ne plante rien. Il s'exécute parfaitement.

Le CDH est un moteur de décision en temps réel : à chaque interaction client (ouverture d'un email, visite d'un espace personnel, appel au centre de relation), il évalue des centaines de stratégies, calcule une propension, applique des règles d'arbitrage (arbitration) et pousse l'offre considérée comme la meilleure (Next-Best-Action). Quand vous modifiez une proposition, un engagement policy ou une condition de suppression, vous ne touchez pas un écran : vous touchez une logique qui se déclenchera des millions de fois, sans qu'aucun humain ne valide chaque diffusion.

C'est précisément ce qui rend le préjudice si particulier. Une erreur dans un rule de decisioning ne génère pas une exception : elle génère un comportement. Et ce comportement, multiplié par la base clients d'une banque ou d'un assureur, devient un événement de masse en quelques heures.

Prenons un scénario réaliste, recomposé à partir d'incidents que connaissent bien les intégrateurs Pega. Un consultant Lead System Architect intervient chez un grand assureur pour ajuster une stratégie d'upsell. L'objectif : proposer une option de garantie à un segment précis de clients éligibles.

Dans la stratégie, une condition d'éligibilité s'appuie sur une propriété calculée. Lors d'un refactoring, la borne de cette condition est inversée : au lieu de cibler les clients dont l'ancienneté dépasse un seuil, le rule cible désormais tous les autres. La logique compile, les tests unitaires passent (ils ne couvraient pas ce segment), la revue ne détecte rien car le diff paraît cosmétique. Le déploiement part en production un mardi soir.

Le rule ne s'est jamais trompé. Il a fait exactement ce qu'on lui a demandé — sur la mauvaise population.

Le lendemain matin, l'offre est partie. Pas vers les 80 000 clients ciblés, mais vers plusieurs millions de clients non éligibles, dont certains à des tarifs que l'assureur ne peut pas honorer. Sur le canal email, c'est récupérable. Sur le canal d'affichage in-app avec engagement contractuel affiché, beaucoup moins.

La tentation, quand on raisonne en ingénieur, est de chiffrer l'incident au temps de correction : quelques heures pour identifier le rule, le corriger, redéployer. Or ce n'est jamais là que se trouve le préjudice.

Le coût réel se compose de strates successives :

• Le manque à gagner ou la perte sèche : les offres honorées à un tarif erroné, les remises consenties à des clients non éligibles, l'effort commercial gaspillé.
• La gestion de crise : cellule de pilotage, communication de rattrapage, mobilisation du centre de relation client pour absorber les appels entrants.
• Les dédommagements : gestes commerciaux pour les clients désarçonnés, voire respect de l'offre erronée pour préserver l'image.
• Le volet réputationnel et réglementaire : dans la banque-assurance, une communication commerciale non maîtrisée à grande échelle attire l'attention.

Aucune de ces strates n'est un dommage matériel. Il n'y a ni matériel détruit, ni local endommagé. C'est un dommage immatériel pur : un préjudice financier qui résulte d'une faute professionnelle, sans atteinte physique préalable. C'est exactement la catégorie la plus délicate à couvrir, et celle que le consultant Pega rencontre en première ligne.

Beaucoup d'indépendants de l'IT pensent être couverts parce qu'ils ont assuré leur poste de travail et leur parc informatique. C'est une confusion fréquente et coûteuse. Une assurance matériel informatique protège vos équipements (ordinateur portable, station de travail, vol, casse, oxydation). Elle est utile, mais elle ne couvre jamais un préjudice causé à un client par une erreur de modélisation.

Le sinistre Pega que nous décrivons relève d'un tout autre mécanisme : la responsabilité civile professionnelle. C'est elle qui prend en charge les conséquences pécuniaires d'une faute, d'une erreur ou d'une négligence commise dans l'exécution de la mission — y compris les dommages immatériels non consécutifs, c'est-à-dire ceux qui ne découlent d'aucun dommage matériel.

Sur ce type de mission, la distinction n'est pas théorique. C'est la différence entre un dossier indemnisé et une mise en cause personnelle que vous assumez sur votre patrimoine.

Pour la plupart des missions IT, un plafond de RC Pro de 150 000 à 500 000 € suffit largement. Le CDH change l'échelle du raisonnement. La grandeur qui détermine votre exposition n'est pas la complexité du rule, mais la taille de la population sur laquelle il s'exécute.

Un préjudice unitaire minuscule, multiplié par plusieurs millions de clients, produit un montant que des plafonds standards ne couvrent pas. C'est la raison pour laquelle les donneurs d'ordre de la banque-assurance, et les contrats-cadres des intégrateurs Pega Partners, exigent désormais couramment des plafonds de 1 M€ pour les missions touchant au decisioning.

Concrètement, avant d'accepter une mission CDH, vérifiez trois points dans votre contrat :

1. Le plafond par sinistre est-il au niveau exigé par le donneur d'ordre (souvent 1 M€) ?
2. Les dommages immatériels non consécutifs sont-ils explicitement couverts, et à quel sous-plafond ?
3. La couverture s'étend-elle à vos missions en France et dans l'UE, fréquentes sur les déploiements Pega Cloud multi-pays ?

Un consultant Pega facturé à juste titre 21,90 €/mois pour sa RC Pro paie un peu plus que d'autres profils IT. Ce différentiel n'est pas arbitraire : il reflète exactement le plafond élevé que vos missions imposent.

L'assurance couvre le sinistre ; elle ne le remplace pas par de bonnes pratiques. Sur le decisioning, quelques réflexes réduisent drastiquement la probabilité du scénario de masse :

• Tester sur la volumétrie réelle : un rule validé sur dix profils ne dit rien de son comportement sur cinq millions. Les simulations de stratégie (Strategy testing, Scenario planner) doivent porter sur des échantillons représentatifs.
• Borner les diffusions : plafonds de volume, fenêtres de contact, listes de suppression robustes. Une erreur bornée à 50 000 envois n'est pas du même ordre qu'une erreur sans limite.
• Déployer progressivement : un déploiement par paliers (canary) sur un sous-segment permet de détecter l'anomalie avant la diffusion totale.
• Tracer les changements : un historique clair des modifications de stratégie est votre meilleur allié pour démontrer le périmètre exact de votre intervention en cas de litige.

Ces pratiques ne vous mettent pas à l'abri d'une mise en cause, mais elles changent la nature de la discussion juridique. Et lorsque la discussion devient juridique, c'est votre RC Pro et sa protection juridique professionnelle qui prennent le relais.

Un dernier point mérite d'être souligné : sur le decisioning, la frontière entre l'erreur du consultant et la décision stratégique du client est parfois ténue. Vous implémentez une logique que le métier a parfois définie sans en mesurer toutes les conséquences à grande échelle. D'où l'importance de formaliser par écrit les arbitrages : un email de validation, une matrice de ciblage approuvée, un compte rendu d'atelier. Ces traces ne ralentissent pas le projet ; elles dessinent précisément le périmètre de votre responsabilité le jour où une offre erronée partira en production. Pour approfondir les couvertures adaptées à votre activité, consultez la page dédiée à l'assurance Consultant Pega.