Trigger Apex en boucle : quand un governor limit fait planter la prod du client
Un trigger Apex mal écrit qui franchit un governor limit peut figer l'ensemble du processus commercial d'un client en pleine production. Décryptage de la chaîne de responsabilité.
- Les governor limits Salesforce (CPU time, 101 SOQL queries, profondeur de récursion) ne sont pas des bugs mais des garde-fous : un code qui les franchit fait échouer toute la transaction du client.
- Un trigger récursif ou mal bulkifié déployé en production peut bloquer la création de comptes, de leads ou d'opportunités pour des centaines d'utilisateurs simultanément.
- La faute de conception (code non bulkifié, absence de récursion guard) engage votre responsabilité civile professionnelle, pas la plateforme.
- Une RC Pro adaptée au conseil et à l'intégration CRM couvre les dommages immatériels subis par le client : perte d'exploitation, heures de réparation, manque à gagner commercial.
Le governor limit n'est pas un bug, c'est un mur
Sur une plateforme multi-tenant comme Salesforce, des milliers d'organisations partagent la même infrastructure. Pour empêcher qu'un code mal écrit ne monopolise les ressources au détriment des autres clients, l'éditeur impose des governor limits : des plafonds stricts par transaction. Vous les connaissez par cœur : 100 requêtes SOQL en mode synchrone, 150 DML statements, 10 000 enregistrements traités par DML, 10 secondes de CPU time, 6 Mo de heap.
La particularité, c'est que ces limites ne se contournent pas : quand votre code les franchit, Salesforce annule l'intégralité de la transaction et lève une exception non rattrapable du type System.LimitException: Too many SOQL queries: 101 ou Apex CPU time limit exceeded. L'utilisateur final, lui, voit simplement son écran se figer ou un message d'erreur s'afficher au moment de sauvegarder un enregistrement.
Le problème, pour un consultant, c'est que ces incidents ne se manifestent presque jamais en sandbox avec trois enregistrements de test. Ils explosent en production, quand un import de 5 000 lignes ou un traitement de masse déclenche un trigger qui n'a jamais été pensé pour gérer des lots.
Les trois scénarios qui figent un CRM en production
Trois fautes de conception reviennent systématiquement dans les sinistres liés à l'Apex :
1. Le trigger non bulkifié
Vous écrivez une requête SOQL à l'intérieur d'une boucle for qui itère sur Trigger.new. En sandbox avec un enregistrement, tout fonctionne. En production, un Data Loader insère 200 lignes d'un coup : votre boucle exécute 200 requêtes et franchit le mur des 100 SOQL. Résultat : l'import entier échoue, et chaque sauvegarde manuelle qui touche cet objet plante aussi.
2. La récursion non maîtrisée
Un trigger after update qui modifie le même objet déclenche... le même trigger. Sans récursion guard (une variable statique de classe), vous obtenez une cascade qui consomme le CPU time ou atteint la profondeur maximale de récursion. Le processus de mise à jour du client se fige.
3. Le déclenchement croisé entre automatisations
Un Flow met à jour un champ, ce qui déclenche un Process Builder, qui déclenche un trigger Apex, qui re-déclenche le Flow. Cet entrelacs d'automatisations héritées de plusieurs prestataires est l'une des causes les plus difficiles à diagnostiquer et les plus coûteuses à corriger.
Chiffrer le dommage : ce que coûte réellement une prod figée
Imaginons un éditeur SaaS dont 80 commerciaux saisissent leurs opportunités dans Sales Cloud. Vous déployez un vendredi soir un trigger censé recalculer un score de priorité. Lundi matin, dès que les commerciaux modifient une opportunité en lot via une vue de liste, le governor limit CPU est franchi et la sauvegarde échoue.
| Poste de préjudice | Estimation |
|---|---|
| Pilotage commercial bloqué (80 users, 4 heures) | Perte d'exploitation difficilement chiffrable |
| Intervention d'urgence d'un autre intégrateur | 3 000 à 6 000 € |
| Reprise manuelle des données saisies hors système | 2 jours-homme |
| Pénalité contractuelle de SLA | selon contrat |
Le client ne vous reproche pas « un bug » au sens abstrait : il invoque un manquement à votre obligation de moyens renforcée, car un consultant certifié est réputé connaître les bonnes pratiques de bulkification documentées par l'éditeur. C'est précisément ce type de dommage immatériel non consécutif (préjudice financier sans dommage matériel ni corporel) que vise une assurance RC Pro taillée pour le conseil informatique.
Obligation de moyens ou de résultat : où se situe votre risque
En droit français, le consultant en informatique est en principe tenu d'une obligation de moyens : vous vous engagez à mettre en œuvre les compétences et diligences d'un professionnel certifié, pas à garantir un résultat absolu. Mais cette qualification se durcit selon la rédaction de votre contrat.
Si votre devis ou votre contrat de prestation mentionne un engagement de « livraison fonctionnelle conforme au cahier des charges » ou des pénalités de retard, le juge peut requalifier tout ou partie de votre prestation en obligation de résultat, où la simple constatation du dysfonctionnement suffit à engager votre responsabilité.
Deux réflexes contractuels limitent l'exposition :
- Décrire précisément le périmètre de la mission et exclure explicitement la responsabilité sur du code hérité d'autres prestataires que vous n'avez pas audité.
- Documenter vos préconisations de tests de charge et de validation avant go-live. Si le client refuse une phase de recette ou impose un déploiement précipité, cette trace écrite réduit votre part de responsabilité.
Ces clauses réduisent le risque mais ne l'annulent pas : le client peut toujours engager une action, et vos seuls frais de défense (expertise judiciaire, avocat) peuvent atteindre plusieurs milliers d'euros avant même qu'une faute soit reconnue.
Pourquoi la garantie de la plateforme ne vous protège pas
Une confusion fréquente : « Salesforce est une plateforme robuste, donc le risque est porté par l'éditeur. » C'est faux. Les conditions générales de l'éditeur excluent expressément sa responsabilité sur le code personnalisé et la configuration réalisés par vous ou par un partenaire. Le governor limit fonctionne exactement comme prévu : c'est votre Apex qui l'a franchi.
La responsabilité remonte donc directement à l'auteur du code. Et si vous intervenez en sous-traitance via une ESN, le contrat-cadre prévoit presque toujours une clause de refacturation : l'ESN, condamnée vis-à-vis du client final, se retournera contre vous. C'est la raison pour laquelle les ESN et grands comptes exigent contractuellement une attestation RC Pro (souvent 1 à 2 M€ de plafond) avant de vous confier la moindre mission.
Au-delà de la faute de code, gardez en tête que votre poste de travail concentre des accès à des CRM clients sensibles : une assurance du matériel informatique protège l'outil de production du freelance contre la casse et le vol, en complément de la couverture de votre responsabilité.
Les réflexes techniques qui désamorcent le risque
Avant d'être une question d'assurance, le governor limit est une discipline de développement. Quelques réflexes systématiques éliminent l'essentiel des sinistres :
- Toujours bulkifier : aucune requête SOQL ni DML à l'intérieur d'une boucle. Vous collectez les identifiants dans une
Set, vous interrogez une fois, vous traitez en mémoire. - Poser un récursion guard : une variable statique de classe (
private static Boolean alreadyRun = false;) qui empêche un trigger de se rappeler lui-même en cascade. - Cartographier les automatisations avant d'ajouter la vôtre : recensez les Flows, Process Builders et triggers existants sur l'objet pour éviter les déclenchements croisés.
- Tester avec du volume : vos classes de test doivent insérer au moins 200 enregistrements d'un coup, pas un seul. C'est la seule façon de reproduire en sandbox le comportement de la production.
- Déployer en milieu de semaine, jamais un vendredi soir, pour disposer d'une fenêtre de surveillance avant le pic d'activité.
Ces pratiques ne sont pas de simples conseils de confort : un juge saisi d'un litige examinera précisément si vous avez respecté les bonnes pratiques documentées par l'éditeur. Leur absence aggrave votre faute ; leur trace écrite la réduit.
La discipline technique et l'assurance ne s'opposent pas : la première réduit la fréquence des sinistres, la seconde absorbe le choc financier du sinistre résiduel qui, statistiquement, finit toujours par survenir sur une carrière de consultant.
Questions fréquentes
Oui, dans la plupart des cas. Les governor limits sont documentés par l'éditeur et un consultant certifié est réputé connaître les bonnes pratiques de bulkification. Un trigger non bulkifié ou une récursion non maîtrisée relèvent d'une faute de conception qui engage votre responsabilité civile professionnelle.
Non. Les conditions générales de l'éditeur excluent sa responsabilité sur le code personnalisé et la configuration réalisés par les consultants et partenaires. Le governor limit fonctionne comme prévu : c'est votre code Apex qui l'a franchi, donc la responsabilité vous revient.
Excluez explicitement dans votre contrat la responsabilité sur le code et les automatisations que vous n'avez pas développés ni audités. Documentez par écrit vos préconisations de tests avant tout déploiement, surtout si vous reprenez un environnement modifié par plusieurs intégrateurs successifs.
En principe, le consultant informatique est tenu d'une obligation de moyens. Mais si votre contrat mentionne une livraison conforme au cahier des charges ou des pénalités de retard, le juge peut requalifier la prestation en obligation de résultat, où le simple dysfonctionnement suffit à engager votre responsabilité.
Elle couvre les dommages immatériels subis par le client : perte d'exploitation, coût de l'intervention d'urgence, reprise des données saisies hors système, ainsi que vos frais de défense (expertise, avocat) même avant qu'une faute soit reconnue.
Souscrivez votre assurance pro en 2 minutes
Toutes nos protections pour votre activité de Consultant Salesforce — attestation immédiate, sans engagement.
* Tarifs indicatifs « à partir de », selon votre profil, votre activité et les garanties choisies. · Voir la fiche Consultant Salesforce →
Article rédigé et vérifié par l'équipe Insurio — Tutassûr, courtier en assurance immatriculé à l'ORIAS sous le n° 22001730. Information à caractère général ne se substituant pas aux conditions de votre contrat.