Le problème n’est pas de produire des chiffres
Les données existent. Le CRM contient les affaires, la facturation contient le chiffre d’affaires, la boîte mail contient les échanges. Produire un total est trivial.
Ce qui ne va pas est ailleurs.
Les définitions flottent. Une affaire « en cours » désigne-t-elle une affaire avec un devis envoyé, ou une opportunité identifiée ? Le chiffre d’affaires est-il compté à la commande, à la facture ou à l’encaissement ? Tant que ces questions n’ont pas de réponse écrite, deux personnes produisent deux chiffres différents de bonne foi, et la réunion se passe à arbitrer des écarts.
La fabrication coûte cher. Exporter, coller, recalculer, mettre en forme : deux heures qui ne produisent aucune valeur, et qui sautent dès que la semaine est chargée. Le rapport devient irrégulier, puis inexistant.
Le contenu est plat. Un tableau de totaux ne dit pas ce qui a changé. Or l’information utile est presque toujours un écart : une affaire qui n’a pas bougé depuis cinq semaines, un client dont le volume baisse, un taux de transformation qui se dégrade sur un canal.
Ce qu’on automatise
La collecte depuis le CRM, la facturation, les agendas et les canaux d’interaction.
Le calcul, sur une définition unique et écrite de chaque indicateur.
La détection d’écarts. Comparaison à la période précédente, à l’an dernier à la même date, à l’objectif, et à la tendance récente.
Les signalements. Affaires immobiles, clients en baisse, devis proches d’expiration, prévision qui s’éloigne de l’objectif.
La rédaction d’un fil lisible, où les chiffres sont calculés et le texte les relie.
La diffusion au bon rythme et aux bons destinataires, avec un périmètre adapté : le commercial voit son portefeuille, la direction voit l’ensemble.
La traçabilité. Chaque chiffre renvoie à la liste des enregistrements qui le composent.
Comment ça marche techniquement — pour qui veut le détail
L’architecture. Trois couches séparées, et cette séparation est ce qui rend l’ensemble maintenable. Collecte : extraction incrémentale vers des tables brutes, horodatées, jamais modifiées. Transformation : des vues SQL nommées qui portent les définitions métier, versionnées dans Git. Restitution : rapport, tableau de bord, export. Changer une définition, c’est modifier une vue et recalculer l’historique — sans avoir rien perdu.
Les définitions comme code. Chaque indicateur est une vue SQL commentée : « chiffre d’affaires signé = somme des montants HT des affaires passées à l’état gagnée dans la période, hors affaires annulées ». Le commentaire fait partie du fichier, versionné à côté de la requête. C’est ce qui permet de répondre à « pourquoi ce chiffre a changé par rapport au mois dernier » par une différence de commit plutôt que par une enquête.
L’historisation. Les indicateurs sont recalculés et stockés à chaque exécution, pas seulement affichés. Sans cela, on perd la capacité de dire ce qu’on croyait savoir à une date passée — question qui compte quand on analyse une décision prise il y a trois mois. Une table snapshot(indicateur, date_calcul, période, valeur, version_definition) suffit.
Le pipeline commercial, correctement modélisé. Le pipeline n’est pas un état, c’est une suite d’événements : une affaire entre dans un étage, en sort, avance ou régresse. En stockant les transitions plutôt que l’état courant, on obtient gratuitement les durées par étage, les taux de passage réels, et la détection d’immobilité. La plupart des CRM ne conservent que l’état courant, ce qui rend ces analyses impossibles — d’où l’intérêt de capter les transitions dès le départ.
La prévision. Pipeline pondéré par les taux de transformation observés par étage sur votre historique, pas par les pourcentages théoriques que proposent les CRM par défaut. Ces taux se recalculent chaque mois sur une fenêtre glissante. On publie un intervalle plutôt qu’un point : annoncer « entre 80 et 120 k€ » est à la fois plus juste et plus utile qu’un « 97 k€ » dont tout le monde sait qu’il est faux.
La détection d’anomalie, sobrement. Écart à la médiane mobile en unités d’écart absolu médian (MAD), qui résiste aux valeurs extrêmes bien mieux que la moyenne et l’écart-type. Sur des séries hebdomadaires courtes, c’est suffisant et explicable. Les méthodes plus élaborées demandent des volumes que la plupart des PME n’ont pas, et produisent surtout de fausses alertes.
La rédaction. Le modèle de langage reçoit un objet de chiffres déjà calculés — valeurs, variations, listes d’affaires concernées — et produit le texte de liaison. Consigne explicite de ne citer que les chiffres fournis, et vérification automatique après coup : tout nombre présent dans le texte produit et absent du jeu de données déclenche un rejet et une nouvelle tentative. Ce contrôle mécanique vaut mieux que n’importe quelle consigne de prompt.
La diffusion et les droits. Le rapport est rendu par destinataire, avec un filtrage appliqué au niveau des requêtes, pas au niveau de l’affichage. Un commercial ne reçoit pas un rapport global dont on aurait masqué des lignes : sa requête ne renvoie que son périmètre. C’est la seule façon fiable de ne pas fuiter, notamment dans les exports.
L’ordonnancement. Timer systemd ou flux n8n planifié, avec contrôle de fraîcheur des sources avant production : si la dernière synchronisation du CRM date de trois jours, le rapport le dit en tête plutôt que de présenter des chiffres périmés comme s’ils étaient d’aujourd’hui.