Avant de lancer un projet IA,
vérifions que l’entreprise peut réellement l’exécuter.

Une entreprise peut avoir des dizaines d’idées IA et pourtant ne pas être prête à en exécuter une seule correctement. Les données sont dispersées, les identités ne se recoupent pas, les métriques changent selon les équipes, les risques sont traités trop tard et personne ne sait qui portera le système après le prototype. Le diagnostic Data & IA sert à rendre cette réalité visible — puis à décider.

01 — Le point de départ : une ambition, pas encore une trajectoire

Le déclencheur est souvent familier : automatiser une tâche, mieux connaître ses clients, prédire un comportement, interroger ses documents ou déployer un assistant. La technologie est accessible. Ce qui l’est moins, c’est la réponse aux questions qui précèdent le modèle : quelle décision doit progresser ? quelles données la décrivent ? qui en est responsable ? comment vérifiera-t-on que le système fonctionne ?

Un diagnostic sérieux commence donc par la stratégie, les processus et les irritants. Il ne demande pas d’abord quel LLM utiliser. Il demande où l’organisation perd du temps, de la qualité, de la confiance ou des opportunités.

02 — Le piège : confondre idée IA et capacité d’exécution

Un atelier d’idéation peut remplir un tableau très vite. Il suffit de demander où l’IA pourrait aider. Le résultat est une liste de chatbots, de prédictions et d’automatisations — rarement un ordre de marche.

La valeur du diagnostic apparaît lorsqu’il rend les prérequis aussi visibles que les opportunités : qualité et droit d’usage des données, continuité historique, modèle d’entités, sécurité, compétences, intégration au SI, adoption métier et capacité de monitoring. Un cas peut être prometteur mais bloqué par la donnée. Un autre peut être peu spectaculaire mais immédiatement activable. Les deux informations sont utiles à la décision.

03 — Auditer le patrimoine data : disponibilité n’est pas exploitabilité

Le premier travail consiste à cartographier les sources, leurs propriétaires, leur fréquence, leur grain, leur historique et leurs droits. Nous cherchons aussi les ruptures : doublons, champs contradictoires, formats instables, changements de définition, périodes manquantes et agrégats impossibles à réconcilier.

Cette approche prolonge des expériences de Data/Customer Analytics et de Customer 360 documentées dans l’Experience Base. Dans un contexte omnicanal, la structuration des données et la réconciliation entre magasin et autres canaux précèdent l’activation CRM. Dans un contexte de valeur client, les indicateurs d’acquisition, de fidélité, de rétention, de LTV et de complémentarité produits ne deviennent comparables qu’après clarification du modèle de données.

Le résultat n’est pas nécessairement une refonte complète. Il peut être un périmètre fiable pour un premier cas, un plan de remédiation ciblé ou une décision de ne pas engager un chantier tant qu’un prérequis n’est pas levé.

04 — Relier les identités : le moment où les chiffres commencent à parler

Une donnée client, produit ou document n’a de valeur analytique que si l’on sait à quelle entité elle se rapporte. La réconciliation multi-source permet de rapprocher des historiques, d’éviter les doublons et de créer une vue partagée par le métier, la data et le CRM.

Le Customer 360 n’est pas présenté comme un produit magique. C’est un pattern : un modèle canonique, des règles de rapprochement, des indicateurs contrôlés et une sortie vers les outils d’activation. La même logique s’étend à un portefeuille produit, à des fournisseurs, à des contrats, à des dossiers ou à des événements.

05 — Passer de la donnée aux cas d’usage

Un cas d’usage n’est pas une technologie. C’est une décision, un utilisateur, une fréquence, une sortie et une responsabilité. La fiche détaillée décrit la valeur attendue, les données nécessaires, les règles métier, les dépendances, le niveau de risque, le scénario build/buy et la manière de mesurer l’adoption.

Les expériences de scoring prédictif, de recommandation, de lead intelligence et de segmentation montrent plusieurs formes d’activation : recalcul récurrent, transmission CRM, règles de next-best-product, priorisation de leads ou ciblage relationnel. Elles sont utilisées ici comme patterns anonymisés, sans leur attribuer de performance générique.

• 01Décrire la décision et la personne qui l’utilise.
• 02Vérifier la donnée, le grain, la fraîcheur et les droits.
• 03Scorer valeur, faisabilité, risque et dépendances.
• 04Choisir un test, un chantier structurant ou un no-go.

06 — Intégrer l’IA sans lui confier la preuve

Une chaîne de fiches IA documentée en interne illustre une règle simple : le LLM intervient dans une chaîne. Les données structurées et les calculs déterministes portent les faits ; le modèle transforme ou explique ; un validateur contrôle la sortie ; le résultat est conservé dans un cache versionné et rafraîchi lorsque l’événement métier le justifie.

Ce pattern est transposable à un assistant documentaire, une synthèse d’audit ou un brief commercial. Il impose un evidence pack : contexte, métriques, benchmarks, signaux, règles, méthodologie et citations internes. Le niveau de confiance distingue le fait, l’interprétation probable, l’hypothèse et la recommandation.

07 — Gouverner avant que le prototype ne devienne un problème

La gouvernance couvre la provenance, les droits, la conservation, les accès, la sécurité, la souveraineté, les données sensibles, la validation humaine et la capacité à expliquer une sortie. Le diagnostic peut identifier les obligations et les contrôles nécessaires ; il ne se présente pas comme une certification RGPD, AI Act ou cybersécurité.

Cette distinction évite deux excès : vendre de la conformité sans preuve, ou traiter la conformité comme une annexe à ajouter après le déploiement. Les contrôles de qualité des données, de calcul, de narration et de restitution doivent être conçus dans le même flux que le cas d’usage.

08 — Construire l’architecture cible et la roadmap

Le diagnostic se termine par un ordre des choses. Le blueprint de moteur data documenté dans l’Obsidian distingue sources, collecte et historisation, normalisation, moteur analytique, interprétation et restitution. Il prévoit aussi les objets de preuve, les métriques, les signaux, les scores, les renderers et les contrôles qualité.

Cette architecture est une cible réutilisable, pas la promesse d’une plateforme universelle déjà déployée. La roadmap sépare les premières actions — cadrage, accès, qualité, modèle minimal, pilote — des chantiers de structuration : industrialisation, gouvernance, monitoring, intégration et diffusion.

09 — Ce que le client reçoit réellement

Le livrable n’est pas une liste de tendances ni un radar de maturité isolé. Il comprend une synthèse exécutive, une cartographie des données et des entités, un diagnostic qualité/gouvernance, une matrice de maturité, un portefeuille de cas d’usage, des fiches détaillées, une architecture cible et une roadmap.

Chaque recommandation doit rester reliée à une preuve, un périmètre et une limite. Cette discipline rend le document discutable par les équipes et réutilisable lors du snapshot suivant.

10 — La vraie valeur : conserver la machine

Un diagnostic peut être vendu comme une mission ponctuelle. Sa valeur augmente lorsqu’il laisse derrière lui une méthode : questionnaires, checklists, schémas, catalogue de métriques, grilles de scoring, playbooks, evidence packs, contrôles et formats de restitution.

Les expériences accumulées en analytics, Customer 360, scoring, recommandation, product intelligence et génération contrôlée constituent les preuves de cette capacité. Le moteur transverse reste à consolider comme actif HOCUS : suffisamment générique pour voyager, suffisamment métier pour ne pas produire des conclusions creuses.