Le CRM partenaire, au quotidien

Le cadre

C'est le CRM qui suit un dossier de rénovation du premier contact à la facture, et qui envoie ses dossiers au CRM d'audit. Plusieurs métiers s'en servent — régies commerciales, commerciaux, confirmateurs, planificateurs — et chacun ne voit que son périmètre. J'y travaille avec un accès en lecture seule à la base : j'écris les migrations, l'équipe les joue.

Des règles de sécurité perdues sans bruit

Au retour de vacances, une planificatrice ne voyait plus les dossiers d'une entreprise partenaire. La cause : une migration d'optimisation avait réécrit quatre fonctions de sécurité en repartant du fichier d'origine, pas de la version en vigueur, et effacé au passage l'accès des planificateurs à toutes les entreprises.

En cherchant, j'ai trouvé plus grave et que personne n'avait signalé : un garde de confidentialité posé en juillet avait été écrasé de la même façon par une migration sur un autre sujet. Des comptes partenaires relisaient des dossiers qui n'étaient pas les leurs. Les deux règles ont été restaurées, puis vérifiées en simulant la session de vrais utilisateurs dans des transactions annulées.

Une règle écrite en découle, ajoutée au guide des migrations : on réécrit une fonction de sécurité à partir de sa dernière version appliquée, et on note dans l'en-tête de quel fichier on est parti.

Mon erreur, et comment je l'ai réparée

Une migration de rattrapage que j'avais écrite devait toucher 31 dossiers. Elle en a modifié 1 234 en production. J'avais chiffré le périmètre avec un critère dans un script, puis écrit la requête avec un autre, sans les confronter — et les comptages de contrôle étaient plafonnés à mille lignes par l'API.

• Mesurer les dégâts exactement. Et vérifier qu'aucun déclencheur ne réagissait à la colonne touchée : aucun envoi vers l'autre CRM, aucun changement de statut n'était parti.
• Revenir en arrière par référence, pas par critère. Le retour arrière liste les 1 203 dossiers un par un, au lieu de recalculer un critère qui venait justement de se tromper. Contrôle au dossier près après exécution ; seul effet résiduel, leur date de mise à jour.
• Empêcher la récidive. J'ai créé un rôle de base de données en lecture seule, dédié à la vérification : la requête de contrôle d'une migration est désormais exécutée avant la livraison, et c'est un copier-coller exact de sa condition.

J'ai annoncé l'erreur et son impact chiffré à l'équipe dès que je l'ai mesurée. Le même jour, les 216 fichiers de migration posés à plat ont été rangés par dossiers, avec une convention écrite.

Ce que j'ai livré

Se connecter en tant qu'un utilisateur

Pour dépanner un utilisateur, le super administrateur peut basculer dans sa vraie session — mêmes droits, écriture comprise — puis revenir à son compte en un clic. La fonctionnalité existait sur le CRM d'audit ; je l'ai reprise ici en l'adaptant.

• Tout est tracé. Sur ce CRM, les changements de statut s'écrivent dans une table d'historique à part. Sans adaptation, l'action la plus courante n'aurait été tracée nulle part pendant une bascule. Le marquage « fait via l'administrateur » couvre cinq tables d'historique au lieu de deux.
• Ne pas couper la personne. Sur l'autre CRM, une déconnexion globale avait coupé un commercial en pleine visite. Pendant une bascule, la déconnexion ne concerne que l'appareil de l'administrateur.
• Tester ce qui doit échouer. Les fonctions ont été appelées sans authentification et avec la clé publique : toutes ont refusé, sans écrire une ligne dans le journal. Une erreur à cet endroit aurait permis d'ouvrir une session sur n'importe quel compte.