Dans un cabinet de conseil, l’argent se gagne au niveau d’une mission isolée, pas du rapport annuel. Un associé sait généralement d’instinct quels projets portent le résultat et lesquels le grignotent, sauf que ce savoir vit dans les têtes et dans des tableurs, pas dans une vue cohérente. L’analytique du conseil ne commence donc pas par des graphiques mais par une question : savons-nous réellement ce qu’une mission précise coûte et rapporte vraiment.
D’après notre expérience, le difficile n’est pas de dessiner un tableau de bord mais d’amener les données de projets, de personnes et de contrats dans un état où les chiffres tombent juste. Nous n’avons pas d’étude de cas toute prête à montrer ici, mais nous avons ce qui compte le plus dans ce type de projet : des ingénieurs data, des architectes BI et des spécialistes ML que nous plaçons dans l’équipe du client pour que ce socle soit construit et maintenu.
Pourquoi un cabinet de conseil a-t-il besoin de sa propre analytique des missions ?
Parce que le modèle économique du conseil est sensible à plusieurs variables à la fois : le tarif, le taux d’occupation des consultants, la delivery face au budget d’heures et la reconnaissance du revenu dans le temps. Qu’une seule glisse et la marge du projet disparaît, souvent avant que quiconque ne le remarque à la clôture mensuelle.
Les systèmes standards ne montrent pas cela comme un tout. L’ERP connaît les factures, l’outil de suivi des temps connaît les heures, le CRM connaît le pipeline et les SIRH connaissent le coût des personnes, mais aucun d’eux ne réunit cela en une image de la rentabilité d’une mission. Une couche analytique dédiée est le point de rencontre de ces mondes, et le moment où un associé dirigeant cesse de piloter au ressenti.
Comment concevoir un entrepôt de données pour les missions de conseil ?
Le socle est un modèle de données qui décrit le fonctionnement réel du cabinet, et non son apparence théorique. Nous le construisons généralement autour de quelques entités clés :
- la mission / le projet comme unité centrale, avec son type de contrat (forfait, régie, retainer),
- le consultant et son rôle, avec son coût, son tarif de vente et sa disponibilité,
- la feuille de temps, rattachée à un projet et à une tâche,
- le contrat et le budget, avec le revenu et le coût prévus,
- le client et le secteur, pour l’analyse du portefeuille et le benchmarking.
Par-dessus, nous posons un modèle dimensionnel classique (faits et dimensions), car il permet de calculer les mêmes mesures selon différents axes, d’un consultant isolé à toute une ligne de métier, sans réécrire la logique à chaque nouvelle question.
Comment construire les tableaux de bord de marge et de taux d’occupation ?
C’est le coeur de la solution, car le COO et les associés y regardent chaque jour. Les tableaux de bord de marge et de taux d’occupation doivent répondre aux questions opérationnelles plus vite qu’il ne faudrait pour les assembler à la main :
- la marge par projet et par client, séparée en prévue et réalisée,
- le taux d’occupation par consultant, équipe et practice, en distinguant heures facturables et non facturables,
- la consommation du budget d’heures et de coûts face au calendrier (proche d’une mesure de burn/EAC),
- le tarif effectif comparé à la grille tarifaire,
- la reconnaissance du revenu et les travaux en cours (WIP) sur les projets facturés par étapes.
L’essentiel est que ces mesures soient calculées une seule fois, au même endroit, avec une définition unique. Sinon, deux départements apportent deux marges différentes en réunion, et la discussion devient une querelle sur le tableur qui dit vrai.
Comment créer des bibliothèques de références et d’estimations ?
Le benchmarking est le moment où les données passées commencent à rapporter dans les propositions futures. À partir de l’historique des projets, nous construisons des bibliothèques de références et d’estimations, c’est-à-dire un savoir structuré sur la durée et le coût réels de types de travaux répétables.
En pratique, cela signifie paramétrer les projets par type, secteur, taille et composition d’équipe, puis calculer les distributions de l’effort réel face aux estimations initiales. Le commerce cesse de chiffrer « au ressenti », et un nouveau manager obtient un point de repère au lieu d’une page blanche. C’est aussi la manière la plus honnête de nommer les projets qui n’arrivent jamais à se clore, et de comprendre pourquoi.
Comment prévoir le pipeline et la capacité ?
Un cabinet de conseil vend le temps de ses équipes : la prévision du pipeline et de la capacité consiste donc à faire coïncider deux courbes, la demande venue du pipeline et l’offre venue des plannings de l’équipe. Si on les regarde séparément, on obtient toujours soit une surchauffe, soit de l’intercontrat.
Nous combinons donc le pipeline pondéré du CRM avec l’affectation prévue et la disponibilité des consultants, afin de faire apparaître les futurs manques et excédents de capacité des semaines ou des mois à l’avance. Cette vue transforme les conversations de direction de réactives en planificatrices : au lieu d’éteindre un manque de personnes au trimestre suivant, vous pouvez recruter plus tôt, déplacer une équipe ou ralentir délibérément la vente sur un domaine saturé.
Comment maintenir la qualité et la cohérence des données sources ?
Le plus beau tableau de bord perd face à une feuille de temps mal affectée : nous traitons donc la qualité et la cohérence des données sources comme une partie à part du projet, pas comme une réflexion après coup. Les problèmes typiques sont prévisibles :
- des heures saisies en retard ou sur le mauvais projet,
- des définitions différentes d’une même notion (ce qui compte comme facturable) selon les départements,
- un décalage entre le contrat dans le CRM et le périmètre de travail réel,
- des trous dans les données de coût des consultants et des sous-traitants.
Nous intégrons donc des validations et des tests de données dans les pipelines de chargement, des alertes sur les trous et un glossaire clair des mesures. L’enjeu n’est pas des données parfaites dès le premier jour, mais des erreurs visibles et corrigées à la source avant d’atteindre l’écran d’un associé.
Quand vaut-il la peine de recourir à des prévisions ML ?
Quand les règles simples et les moyennes ne suffisent plus, et que l’historique est déjà assez fourni pour que des motifs apparaissent. Les prévisions ML ne remplacent pas les tableaux de bord ; elles ajoutent une couche de prédiction là où une personne ne peut pas peser toutes les dépendances.
Dans le conseil, cela a le plus souvent du sens pour prédire la probabilité de signature d’une opportunité du pipeline, prédire le dépassement de budget d’un projet à partir de signaux précoces et prévoir le taux d’occupation des équipes sur les périodes à venir. C’est une compétence réelle que nous fournissons, même si nous le disons clairement : le ML n’a de sens que sur des données propres, c’est donc généralement une étape ultérieure, pas la première.
Quelles compétences fournissons-nous pour ce type de projet ?
Nous construisons l’équipe autour du travail concerné, pas « au cas où ». Sur les projets analytiques pour cabinets de services professionnels, ce sont généralement :
- un ingénieur data qui construit les pipelines et l’entrepôt (ELT/ETL, modélisation),
- un architecte / analyste BI responsable du modèle de mesures et de la couche de tableaux de bord,
- un analytics engineer qui veille sur les définitions et les transformations,
- un spécialiste ML là où interviennent les prévisions,
- un spécialiste DevOps / plateforme data pour le déploiement, la sécurité et la maintenance.
Ce dispositif permet à une équipe de prendre réellement en charge la couche de données, au lieu de livrer un seul rapport et de disparaître.
Comment faisons-nous chez RITS ?
Nous le faisons comme partenaire nearshore depuis la Pologne qui place des compétences data, BI et ML dans le projet, même quand c’est votre équipe qui donne la direction :
- nous renforçons l’équipe avec des spécialistes précis dont nous vérifions les compétences avant le démarrage,
- nous concevons le modèle de données du cabinet avant qu’il n’existe le moindre graphique,
- nous réunissons les sources (ERP, suivi des temps, CRM, SIRH) en un entrepôt maintenable,
- nous ajoutons la couche ML seulement là où les données y sont prêtes, sans promesses que nous ne pourrions tenir.
Nous ne prétendons pas avoir un déploiement achevé à montrer dans ce domaine ; nous apportons les personnes et l’approche qui font qu’un tel déploiement se réalise dans votre cabinet et reste maintenu.
Par où commencer avec l’analytique des missions de conseil ?
Partez d’une décision que vous voulez mieux prendre, par exemple « devons-nous prendre ce projet avec cette équipe », et de la question des données nécessaires. Cela définit le périmètre de la première itération de l’entrepôt, le jeu de mesures et les rôles nécessaires. Un tableau de bord de marge digne de confiance vaut mieux que dix auxquels personne ne croit. Nous avons traité les différences entre modèles de collaboration dans notre article sur les modèles de collaboration IT.
Vous construisez l’analytique et le benchmarking des missions de conseil ? Parlons-en - nous accorderons une équipe data/BI/ML et une architecture à votre cabinet.
Construisez avec nous l’analytique et le benchmarking des missions de conseil