Pas un tableau de bord de plus. Un outil de pilotage conçu à partir des décisions que vous prenez — pas des données que vous avez. C'est la différence entre informer et faire agir.
Notre diagnostic gratuit de 5 jours cartographie vos sources de données, mesure votre maturité décisionnelle (Data Readiness Index™), identifie les 3 dashboards qui auront le plus d'impact et vous livre un plan d'action chiffré.
L'industrie part des données pour remonter vers la décision. Nous faisons l'inverse. On commence par ce que le dirigeant doit décider, on identifie le minimum de données nécessaires, et on ne construit que ce qui sera utilisé.
« Quelle décision prenez-vous le plus souvent avec le moins de visibilité ? » C'est la première question. Pas « quels KPIs voulez-vous ? » — cette question-là génère des listes interminables.
Chaque décision génère un « contrat de données » — la liste minimale, pas exhaustive. 45 mesures ciblées valent plus que 340 mesures livrées par habitude. Le modèle est plus léger, plus rapide, plus utilisé.
Le DG voit vert/orange/rouge en 3 secondes. Il clique, il comprend, il décide. En 30 secondes. Le dashboard n'est pas un outil de consultation — c'est un réflexe de pilotage quotidien.
N'importe quel cabinet peut construire un dashboard. La vraie question est : sera-t-il encore utilisé dans 12 mois ? Nous avons formalisé trois outils propriétaires pour mesurer, garantir, et maintenir la valeur de chaque projet BI — avant, pendant, et après.
Votre organisation est-elle prête pour un projet BI ? Nous évaluons 5 dimensions lors du diagnostic gratuit. Le résultat détermine la formule recommandée — et nous dit honnêtement si le projet a des chances de réussir.
Aucun dashboard ne passe en production sans valider ces 5 critères. C'est notre engagement qualité — si un critère échoue, on reste une semaine de plus. À nos frais.
Score de santé sur 100, mesuré chaque trimestre. Au-dessus de 80, le dashboard est vivant. En dessous de 50, il meurt — et nous intervenons avant qu'il soit trop tard.
Pas la méthode vue du consultant — le parcours vu du client. Voici exactement ce qui se passe quand vous travaillez avec nous, ce que ça vous demande, et quand vous voyez le premier résultat.
Nous nous asseyons avec le décideur final — DG, Ministre, Secrétaire Général. Pas de PowerPoint. Pas de questionnaire. Une conversation d'une heure sur les décisions qu'il prend chaque semaine avec un sentiment d'incertitude. C'est cette conversation qui détermine tout le projet.
On ouvre vos fichiers Excel, votre ERP, vos bases Access. On compte les cellules vides, les doublons, les formats incohérents. On ne produit pas un audit de 40 pages — on produit une maquette cliquable de votre futur dashboard, construite sur vos données réelles. À la fin de cette semaine, vous voyez à quoi ressemblera votre outil de pilotage.
On construit le flux de données : source → nettoyage → modèle → dashboard. Le moment clé arrive quand le chiffre du dashboard correspond au chiffre que votre DAF calcule manuellement dans son Excel. Ce test de réconciliation est décisif — c'est lui qui construit la confiance dans le système. Tant que le DAF ne dit pas « oui, c'est le bon chiffre », on ne passe pas à la suite.
C'est la phase la plus intense côté client — et la plus déterminante. Chaque soir, on publie une version du dashboard. Chaque matin, le référent métier dit ce qui parle et ce qui ne parle pas. Les graphiques 3D disparaissent. Les 47 filtres deviennent 5. Les titres en jargon BI deviennent du langage métier. En 10 jours, le dashboard passe de « techniquement correct » à « je comprends tout en 3 secondes ».
Le référent métier doit, seul, sans aide, ajouter un nouveau visuel au dashboard, modifier un filtre, et expliquer un chiffre à son directeur. Si c'est réussi, le dashboard est officiellement vivant. Si ce n'est pas réussi, on reste une semaine de plus — à nos frais. Notre contrat ne prévoit pas un nombre de jours. Il prévoit ce résultat.
Le plus grand risque n'est pas l'échec technique — c'est la mort lente. Le dashboard fonctionne, mais progressivement personne ne le met à jour. Notre protocole inclut un cahier de vie (qui utilise quoi, quand, pour quelle décision), des check-ups trimestriels (une demi-journée pour recalibrer le dashboard avec l'évolution des besoins), et un test de vitalité à 12 mois sur trois indicateurs : fréquence de connexion, nombre de rafraîchissements, nombre de modifications par le référent.
Chaque organisation a un point de départ différent. Nos formules s'adaptent — mais la méthode Decision-First et le transfert de compétences sont non négociables.
Huit situations réelles. À gauche, le quotidien sans dashboard décisionnel. À droite, le quotidien avec.
La puissance d'un dashboard dépend de ce qui se passe en dessous. Voici l'architecture que nous déployons — et pourquoi chaque couche existe.
Stockage de données semi-structurées et non structurées au format Delta/Parquet. Idéal quand les sources sont hétérogènes (Excel + APIs + fichiers plats). Les notebooks Spark permettent des transformations complexes — jointures multi-sources, nettoyage avancé, agrégations.
Entrepôt de données SQL traditionnel sur Fabric. Requêtes T-SQL standard, vues matérialisées, procédures stockées. Idéal quand l'équipe IT maîtrise déjà SQL et quand les sources sont essentiellement relationnelles (ERP, bases SQL).
Le Semantic Model — la couche Gold — est le contrat entre la donnée et le dashboard. C'est un modèle en étoile (tables de faits + tables de dimensions) avec des mesures DAX nommées, documentées, et versionnées. C'est cette couche qui garantit qu'un « chiffre d'affaires » signifie la même chose pour le DAF, le directeur commercial et le DG. Sans Semantic Model partagé, chaque département calcule différemment — et les comités de direction deviennent des débats sur les chiffres au lieu de débats sur les décisions.
Vous avez des données dans Sage, des fichiers Excel, un serveur SQL, peut-être un datawarehouse vieillissant. Voici comment nous vous emmenons vers Microsoft Fabric sans interrompre vos opérations.
Nous cartographions l'intégralité de vos sources de données : ERP (Sage, SAARI, Business Central), bases SQL, fichiers Excel, APIs tierces. Chaque source est évaluée : qualité, volume, fréquence, criticité. Le Data Readiness Index™ mesure votre maturité sur 5 dimensions. Livrable : rapport de diagnostic data + roadmap de migration priorisée.
Nous créons votre workspace Fabric et configurons les pipelines d'ingestion via Dataflow Gen2 et Data Factory. Chaque source est connectée, les données brutes atterrissent dans la couche Bronze du Lakehouse. Le nettoyage et la transformation produisent les couches Silver (données propres) puis Gold (modèle sémantique). Stockage unifié dans OneLake — une seule copie de chaque donnée, accessible partout.
Les pipelines sont orchestrés : rafraîchissement planifié (quotidien, horaire ou en temps réel selon la source), alertes data-driven (seuils dépassés, anomalies détectées), distribution automatique de rapports par email ou Teams. Power Automate déclenche les notifications métier. Le monitoring Fabric surveille la consommation de CU et optimise les coûts. Livrable : plateforme data opérationnelle, autonome, surveillée.
Après la migration : toutes vos données dans un seul Lakehouse. Plus de serveurs à maintenir. Des coûts prévisibles. Et surtout : vos données sont prêtes pour les dashboards, l'automatisation et la gouvernance. La migration n'est pas une fin — c'est le socle sur lequel tout le reste s'appuie.
Un dashboard sans gouvernance meurt en 6 mois. Voici comment nous structurons le cycle de vie complet, du développement à la production.
Workspace DEV
Itérations libres
Données de test
Workspace TEST
Validation métier
Données réelles filtrées
Workspace PROD
Audiences configurées
RLS activé · SLA défini
Le développement DAX et le design des visuels se font dans Power BI Desktop. La publication se fait vers le workspace DEV. Les Deployment Pipelines de Fabric assurent la promotion automatisée DEV → TEST → PROD avec changement automatique des sources de données à chaque étape. Aucune modification manuelle en production.
Les rapports en production sont distribués via les Power BI Apps — pas par partage direct de workspace. Chaque App cible une audience définie (direction, managers, analystes). Les audiences contrôlent qui voit quoi, sans multiplier les rapports. Un seul rapport, plusieurs vues grâce au RLS.
Les datasets validés sont certifiés (badge visible dans le catalogue). Seuls les référents formés peuvent certifier. Les datasets non certifiés restent dans les workspaces DEV — jamais en production. C'est le mécanisme qui évite la prolifération de rapports « sauvages » avec des chiffres contradictoires.
SLA de rafraîchissement : nous définissons avec le client un SLA explicite pour chaque dashboard. Exemple : « les données financières sont mises à jour chaque jour à 6h, le dashboard est consultable à 7h, avec un taux de disponibilité de 99,5% sur le mois. » Ce SLA est documenté dans le cahier de vie du dashboard et vérifié lors des check-ups trimestriels.
Le choix du mode de stockage détermine la performance, la fraîcheur des données et le coût. Voici le comparatif que nous utilisons pour chaque projet.
Les données sont copiées dans le moteur VertiPaq en mémoire. Chaque requête est instantanée.
Taille max : 1 Go (Pro), 10+ Go (Premium/PPU). Le rafraîchissement complet peut être long sur de gros volumes — le rafraîchissement incrémentiel résout ce problème.
Sources stables, volumes modérés, besoin de performance maximale et de toutes les fonctionnalités DAX. C'est le mode de la majorité de nos sprints.
Lecture directe des fichiers Delta dans OneLake. Performance proche de l'Import, fraîcheur quasi temps réel.
Exclusif à Fabric. Pas de colonnes calculées ni de tables calculées. Fallback automatique en DirectQuery si le modèle utilise des vues SQL ou du RLS sur l'endpoint SQL. Toutes les tables doivent être dans le même Lakehouse.
Volumes importants déjà dans Fabric/OneLake, besoin de fraîcheur sans gestion de rafraîchissement. Le meilleur compromis quand l'infrastructure Fabric est en place.
Les requêtes sont envoyées en temps réel à la source. Aucune copie des données dans Power BI.
Performance totalement dépendante de l'optimisation de la base source. Charge sur le système source à chaque interaction utilisateur. Fonctionnalités DAX réduites. Pas de hiérarchies de dates automatiques.
Volumes très importants (centaines de Go), données qui changent en continu (IoT, transactions), ou quand la réglementation interdit la copie. Réservé aux cas où aucune alternative n'est viable.
Notre recommandation : pour un premier sprint, nous utilisons l'Import — c'est le plus simple, le plus rapide, et le plus compatible avec l'ensemble des fonctionnalités DAX. Le passage à Direct Lake se fait quand l'organisation migre vers Fabric et que les volumes le justifient. Le DirectQuery n'est proposé que pour des cas spécifiques (données temps réel, contraintes réglementaires). On ne choisit jamais un mode par dogmatisme — on choisit celui qui sert la décision du DG.
Un dashboard partagé à 60 utilisateurs ne signifie pas que tout le monde voit la même chose. Voici les mécanismes de sécurité que nous déployons systématiquement.
Le directeur de la filiale Bouaké voit les données de Bouaké. Le DG voit toutes les filiales. Le même rapport, les mêmes mesures DAX, mais les données sont filtrées automatiquement selon le profil de l'utilisateur. Le RLS est défini dans le modèle sémantique et appliqué côté serveur — l'utilisateur ne peut pas contourner le filtre.
Le responsable commercial voit le chiffre d'affaires mais pas la marge nette. Le DAF voit les deux. L'OLS masque des colonnes ou des mesures entières selon le profil — pas un filtre sur les lignes, mais une restriction sur les colonnes visibles. Indispensable quand le même rapport sert des profils avec des niveaux de confidentialité différents.
Chaque dataset et chaque rapport reçoit une étiquette de sensibilité : Public, Interne, Confidentiel, Hautement confidentiel. L'étiquette détermine qui peut exporter, imprimer ou partager le rapport. Un rapport « Confidentiel » ne peut pas être exporté en PDF par un utilisateur standard — la protection suit le fichier, même hors Power BI.
Pour les clients européens et les organisations internationales : les capacités Fabric sont déployées dans la région de votre choix (Europe, Afrique du Sud). Les données ne quittent pas la région désignée. Les journaux d'audit Power BI tracent chaque accès, chaque export, chaque partage — un prérequis pour les organisations soumises à la Convention de Malabo ou aux lois nationales de protection des données en Afrique.
Un dashboard lent est un dashboard abandonné. Voici les pratiques d'optimisation que nous appliquons systématiquement — et les outils que nous utilisons pour les diagnostiquer.
Tables de faits au centre, tables de dimensions autour, relations unidirectionnelles. Pas de snowflake. Pas de relations bidirectionnelles sauf cas documenté. Chaque déviation de ce modèle est une dégradation de performance mesurable. Nous forçons cette discipline dès la conception — pas en optimisation après coup.
Les mesures itératives (SUMX, FILTER) parcourent chaque ligne — acceptable sur 10 000 lignes, catastrophique sur 10 millions. Nous privilégions les fonctions de contexte (CALCULATE, ALLEXCEPT) qui exploitent le moteur VertiPaq en colonnes. Chaque mesure complexe est testée dans DAX Studio avant déploiement.
Sur un dataset de 3 ans, seuls les 30 derniers jours sont rafraîchis à chaque cycle. Les données historiques sont partitionnées et ne bougent pas. Résultat : un rafraîchissement qui passe de 45 minutes à 3 minutes. Disponible en Power BI Premium/PPU et en Fabric.
Performance Analyzer dans Power BI Desktop mesure le temps de rendu de chaque visuel — si un graphique prend plus de 2 secondes, on le diagnostique. DAX Studio permet d'exécuter et profiler chaque requête DAX individuellement. Tabular Editor pour la gestion avancée du modèle, les best practice rules, et le déploiement automatisé.
Notre standard : aucun visuel ne doit dépasser 3 secondes de chargement sur une connexion standard. C'est le seuil au-delà duquel l'utilisateur perd patience et retourne à son fichier Excel. Ce standard est mesuré et documenté dans le cahier de vie du dashboard.
Choisir la bonne licence Power BI est une décision architecturale, pas administrative. Mauvais choix = surcoût de milliers d'euros ou fonctionnalités critiques verrouillées. Cette section vous donne tout ce qu'il faut pour décider — sans avoir besoin de chercher ailleurs.
Depuis avril 2025, Microsoft a augmenté les prix Power BI de 40% (Pro) et 20% (PPU). Les P-SKU Premium sont retirés pour les nouveaux clients — remplacés par les F-SKU Fabric. Voici l'état des lieux à jour.
Création de rapports dans Desktop. Publication limitée. Pas de partage ni de collaboration.
Pas de partage, pas de collaboration, pas de workspaces partagés. Peut consulter des rapports si ceux-ci sont hébergés sur une capacité F64+ ou Premium.
Utilisateur individuel qui explore ses données en local, ou viewer dans une organisation qui a déjà une capacité Fabric F64+.
Licence de base pour créer, publier et partager des rapports. Tous les créateurs ET consultants doivent avoir une licence Pro.
Pas de Deployment Pipelines (DEV→TEST→PROD), pas de rapports paginés, pas de XMLA read/write, pas d'AI/Copilot, pas de Direct Lake, datasets limités à 1 Go. Chaque viewer doit aussi payer une licence Pro.
Équipe de 5-50 personnes qui crée et consulte des rapports. Sources simples (Excel, ERP unique), volumes modérés. C'est le point de départ de nos sprints.
Toutes les fonctionnalités Premium, facturées par utilisateur. Idéal pour les équipes data avancées sans investir dans une capacité dédiée.
Le contenu PPU ne peut être partagé qu'avec d'autres utilisateurs PPU. Pour partager avec des utilisateurs Pro ou Free, le contenu doit être sur une capacité Fabric F64+. Pas de viewers gratuits en mode PPU seul.
Deployment Pipelines (DEV→TEST→PROD), rapports paginés, XMLA read/write, Dataflows Gen2, AI/Copilot, datasets 100 Go, 48 refresh/jour. Rentable pour les équipes de 5-250 power users qui ont besoin de ces fonctionnalités avancées.
Depuis juillet 2024, les P-SKU Premium sont retirés pour les nouveaux clients. Fabric (F-SKU) est le seul modèle capacité disponible. Le principe : vous payez de la puissance de calcul partagée (Capacity Units), pas des licences par utilisateur. Power BI, Data Factory, Spark, Real-Time Analytics — tout consomme des CU du même pool.
Les créateurs de contenu ont toujours besoin d'une licence Pro ($14/mois) pour publier. Mais les viewers peuvent consulter gratuitement si la capacité est F64 ou supérieure.
| SKU | CU | Prix PAYG | Prix réservé 1 an | Cas d'usage |
|---|---|---|---|---|
| F2 | 2 | ~263 $/mois | ~156 $/mois | Développement, tests, POC |
| F4 | 4 | ~526 $/mois | ~313 $/mois | Petite équipe, 1-2 dashboards |
| F8 | 8 | ~1 051 $/mois | ~626 $/mois | PME, 3-5 dashboards |
| F16 | 16 | ~2 102 $/mois | ~1 251 $/mois | Département, datasets moyens |
| F32 | 32 | ~4 205 $/mois | ~2 502 $/mois | Multi-départements, Spark |
| F64 ★ | 64 | ~8 409 $/mois | ~5 004 $/mois | Viewers gratuits · Enterprise |
| F128 | 128 | ~16 819 $/mois | ~10 008 $/mois | Grande entreprise, workloads lourds |
Verdict : pour 60 utilisateurs, le scénario Pro (A) ou PPU mixte (C) est le plus économique à environ 10 000 $/an. Le F64 à ~60 000 $/an (réservé) ne devient rentable que quand le nombre de viewers dépasse ~350 utilisateurs ou quand les fonctionnalités Fabric (Direct Lake, pipelines de données, Spark, volumes 400 Go+) sont indispensables. Le seuil n'est pas le nombre d'utilisateurs seul — c'est la combinaison volume + fonctionnalités + nombre de viewers.
Au-delà du prix, la vraie question est : quelles fonctionnalités votre organisation va-t-elle utiliser ? Voici ce qui est verrouillé en Pro et débloqué en PPU ou Fabric.
En Pro, vous êtes limité à 8 rafraîchissements par jour. Pour un dashboard financier mis à jour en continu par l'ERP, c'est insuffisant. En PPU/Fabric, 48 refresh/jour — soit un toutes les 30 minutes. Pour le quasi temps réel, Direct Lake (Fabric uniquement) élimine le besoin de refresh en lisant directement les fichiers Delta dans OneLake.
Promotion automatisée DEV → TEST → PROD avec changement automatique des sources de données par environnement. Impossible en Pro — les déploiements sont manuels, ce qui signifie erreurs humaines et pas de validation métier formalisée. C'est la base de notre gouvernance (section ci-dessus).
En Pro, chaque dataset est limité à 1 Go. Pour consolider finance + supply chain + RH dans un seul modèle sémantique, 1 Go est vite atteint. PPU repousse à 100 Go, Fabric à 400 Go par dataset. La consolidation multi-domaines nécessite ce headroom.
Les rapports paginés (format SSRS) sont indispensables pour les états financiers normés, les bons de commande, les rapports réglementaires. Ils génèrent des PDF formatés à l'identique quelle que soit la taille des données. Verrouillés en Pro, disponibles dès le PPU.
Le point d'accès XMLA permet d'administrer le modèle sémantique depuis des outils tiers (Tabular Editor, ALM Toolkit, DAX Studio en mode écriture). Indispensable pour le déploiement automatisé, les scripts de migration, et l'audit détaillé des modèles. Pro ne donne aucun accès XMLA.
Copilot dans Power BI permet de créer des visuels, écrire du DAX, et interpréter les tendances en langage naturel. AutoML et Cognitive Services sont aussi disponibles. Ces fonctionnalités AI ne sont accessibles qu'en PPU ou Fabric — verrouillées en Pro. Microsoft a justifié la hausse de prix 2025 par cet investissement AI.
Application Power BI officielle qui affiche la consommation de CU en temps réel par workload (Power BI, Data Factory, Spark). Détecte les pics de consommation, les rafraîchissements qui consomment trop, les requêtes qui saturent la capacité. Configurée dès le déploiement.
En PAYG, la capacité peut être mise en pause (nuits, weekends) et le scaling up/down s'adapte à la charge. La réservation 1 an économise ~40% vs PAYG — F64 passe de ~8 409 $ à ~5 004 $/mois. Nous dimensionnons la capacité pendant le diagnostic.
Quand la capacité est saturée, les tâches background sont ralenties pour préserver l'interactivité des rapports. L'option « capacity overage » paie le surplus plutôt que de subir des ralentissements. Alertes configurées pour que le DSI soit prévenu avant les utilisateurs.
Estimez vos coûts mensuels pour n'importe quelle combinaison de services Azure, dont Fabric.
azure.microsoft.com/pricing/calculator →Entrez vos workloads (Power BI, Spark, Data Factory) et obtenez le F-SKU recommandé avec le détail des CU.
microsoft.com/fabric/capacity-estimator →Microsoft offre un essai Fabric F64 pendant 60 jours — suffisant pour tester vos workloads réels et mesurer la consommation avant d'acheter.
Démarrer l'essai gratuit →Note : les prix ci-dessus sont basés sur la région US West 2 (~0,18 $/CU/heure). Les prix varient de ±10-15% selon la région Azure (West Europe : ~0,22 $/CU/heure). Utilisez le calculateur Azure avec votre région pour un chiffrage précis.
NJIADATA ne vend pas de licences Microsoft. Nous recommandons le dimensionnement adapté à votre réalité — pas celui qui maximise la facture. Le choix de licence est validé pendant le diagnostic gratuit, avec un chiffrage précis adapté au nombre d'utilisateurs, aux volumes de données, et aux fonctionnalités requises par votre DSI.
Les questions que nos prospects posent le plus souvent — et nos réponses honnêtes.
Non. C'est même le cas le plus fréquent. Le sprint est conçu pour travailler avec des données « good enough » — fichiers Excel désorganisés, bases Access, ERP partiellement renseigné. Ce qu'on ne peut pas faire, c'est créer des données qui n'existent pas. Si vous n'avez aucun suivi budgétaire ni aucune base client, le premier chantier sera la structuration, pas la BI — et nous le disons avant de signer.
La plupart des projets BI échouent pour la même raison : le consultant a construit un système qui répond aux spécifications, pas aux besoins du décideur. Notre approche commence par l'entretien avec le DG — pas par l'inventaire des données. Le dashboard est conçu pour changer une décision précise, pas pour « donner de la visibilité ». Et le test d'autonomie en semaine 6 garantit que vos équipes savent l'utiliser et le faire évoluer. Un dashboard que personne n'utilise n'est pas un risque qu'on accepte de prendre.
Vos équipes. C'est tout l'objet du transfert de compétences : le kit d'autonomisation (guide, catalogue de visuels, documentation DAX, thème réutilisable) et le binôme de 2 référents formés permettent à votre organisation de créer les dashboards suivants sans nous. Les check-ups trimestriels de la première année sont là pour s'assurer que l'autonomie est réelle, pas théorique.
Ça dépend du profil d'utilisation. Si les 60 utilisateurs créent et modifient des rapports, il faut 60 licences Pro ($14/mois chacune, soit ~10 080 $/an). Si la majorité ne fait que consulter, une approche mixte (PPU pour les créateurs + Pro pour les viewers) coûte ~10 680 $/an avec des fonctionnalités avancées pour les builders. Le F64 (~60 000 $/an réservé) ne se justifie qu'au-delà de ~350 viewers. Nous dimensionnons les licences pendant le diagnostic — c'est l'un des livrables de la semaine 1. Voir notre guide licensing complet dans la section ci-dessus.
Oui. Power BI dispose de connecteurs natifs pour SAP HANA, SAP BW, Sage 100/X3, et la plupart des ERP du marché. Nous avons l'expérience des connexions à des environnements variés — y compris des systèmes anciens avec export CSV comme seule option. Le diagnostic de la semaine 1 inclut le test de connexion à vos sources réelles.
Oui. Beaucoup de nos clients en Afrique n'ont pas de direction informatique structurée. Le sprint est conçu pour fonctionner avec un interlocuteur technique minimal — quelqu'un qui connaît les accès aux systèmes et aux fichiers. Le référent métier qui itère avec nous pendant les semaines 4-5 est quelqu'un du métier, pas de l'IT. Et le kit d'autonomisation est conçu pour des utilisateurs métier, pas pour des informaticiens.
Un freelance construit ce que vous lui demandez. Nous construisons ce dont vous avez besoin — et la différence n'est pas toujours la même chose. L'entretien décideur, le contrat de données, le protocole d'ancrage et le transfert de compétences ne sont pas des prestations qu'un freelance propose habituellement. Surtout, notre engagement porte sur un résultat (le test d'autonomie), pas sur un nombre de jours.
Les deux. L'entretien décideur et les sessions d'itération des semaines 4-5 sont plus efficaces en présentiel — surtout pour le premier projet. Le développement technique (pipeline, modèle, DAX) se fait à distance. Pour les clients en Afrique de l'Ouest, nos équipes sont basées à Abidjan. Pour les organisations internationales, nous intervenons depuis Paris avec des déplacements sur site aux moments clés.
Le diagnostic de 5 jours est gratuit et sans engagement. En une heure avec votre DG, nous identifions les décisions qui comptent. En 5 jours, vous avez la maquette de votre futur dashboard — sur vos données réelles.
Demander un diagnostic gratuit →Vous hésitez entre ERP, BI et GED ? Le diagnostic transversal de 5 jours cartographie vos besoins avant tout engagement.