Le CRM commercial, côté direction

Reprendre un projet qui a avancé sans moi

Au retour de deux mois d'absence, l'équipe avait livré quatre-vingts commits, et l'historique de la branche principale avait été réécrit : ma copie locale n'avait plus d'ancêtre commun avec elle. J'ai comparé les contenus avant toute action, gardé une branche de sauvegarde, puis réaligné sans rien perdre. J'ai ensuite relu l'ensemble et rédigé une note de reprise en sept parties, pour arriver à la réunion client en sachant ce qui avait été livré et ce qui restait en débat.

Un tableau de pilotage honnête

La direction du client a transmis une spécification d'une centaine d'indicateurs. En la lisant, il est apparu que ce n'était pas une liste à brancher : une partie reposait sur des données que l'outil ne connaît pas du tout. J'ai classé les douze sections par difficulté, et montré que le vrai sujet était la saisie des données, pas le calcul.

J'ai livré ce qui pouvait l'être sans attendre : un panneau « Pilotage direction » construit uniquement sur des données existantes et remplies — marge signée et abandonnée, pipe pondéré, taux de conclusion, écart moyen au MWh pondéré par le volume, concentration sur un client ou un commercial, et des alertes sur les affaires immobiles. Le calcul est isolé dans une fonction testée par dix-huit tests.

• Aucune tuile sans donnée. Une tuile qui affiche 0 € parce que la donnée n'existe pas fait douter de toutes les autres. Les indicateurs sans source n'ont pas été affichés.
• Absent n'est pas non chargé. Si le suivi des affaires ne se chargeait pas, toutes se seraient affichées « sans échange » sur l'écran de la direction. Le code distingue maintenant les deux cas, avec un test dédié.
• Vérifier en base avant d'écrire au client. Ma première analyse affirmait qu'une donnée n'existait pas : j'avais lu les types du code plutôt que la base. Trois erreurs corrigées avant l'envoi — et un constat clé pour la réunion : seulement vingt et une affaires saisies, aucune depuis fin juin.

Une erreur de ma part au passage : j'ai poussé sur la branche principale d'un dépôt partagé sans vérifier la convention de l'équipe. Je l'ai annulée par un commit inverse — sans réécrire l'historique, pour que les collègues n'aient rien à faire — puis reporté le travail sur une branche de fonctionnalité.

Une réunion de cadrage préparée en urgence

Le module Production avait été construit par l'équipe pendant mon absence, et la réunion de cadrage avec le client arrivait. J'ai préparé un guide à partir du code et de la base réels : l'essentiel en une minute, le vocabulaire du métier, ce qui existe et ce qui reste à construire, les sept questions bloquantes, et ce qu'il ne fallait pas promettre.

Pendant la réunion, j'ai servi d'appui en direct pour répondre aux questions et noter les décisions : qui fait passer un dossier en production, un contrôle qualité par opération plutôt que par dossier, une liste paramétrable des dossiers concernés. Le compte rendu a ensuite consigné toutes les règles tranchées, et j'ai comparé notre version à celle diffusée par le client pour reporter les trois écarts d'interprétation.

Un classeur de direction lu par script

La direction a ensuite envoyé son classeur de pilotage : quinze onglets, plusieurs milliers de formules, un dictionnaire d'environ cent trente définitions. Trop dense pour être lu à la main de façon fiable : je l'ai extrait onglet par onglet par un script — valeurs, formules, listes déroulantes — avant de le lire.

J'ai rapproché ses 43 colonnes de saisie du modèle de données du CRM, puis ses indicateurs des données réellement disponibles. Le document qui en est sorti dit ce qui existe, ce qui manque, onze points à trancher, et un découpage en sept lots. Deux propositions en tête : une table de correspondance entre les étapes du classeur et celles du CRM, plutôt que de renommer un pipeline dont tous les commerciaux se servent ; et des données RH réservées à la direction par une permission.