Les fondations de données avant l'IA : des corrections rentabilisées en deux trimestres

La plupart des plans d'IA partent du principe que les données de l'entreprise sont prêtes et que le travail consiste à choisir un modèle. Dans les entreprises établies, les données se trouvent généralement dans les bons systèmes, mais sous la mauvaise forme : un même client enregistré de trois façons, des références produits qui ne désignent pas la même chose dans la boutique et dans l'entrepôt, un chiffre d'affaires qui diffère entre la propriété d'analytics et le grand livre.

Le moyen le plus rapide de savoir quoi corriger est de suivre des enregistrements réels. Prenez un échantillon de commandes, de factures et de mouvements de stock et retracez chacun d'eux dans tous les systèmes qu'il traverse, de la boutique ou de l'outil de devis au logiciel comptable et à la couche de reporting, en passant par le prestataire de paiement, le CRM et l'entrepôt. Notez où l'enregistrement est ressaisi à la main, où un tableur le copie, où son identifiant change et où il disparaît. Ces points constituent la liste des travaux.

Les corrections ci-dessous sont celles dont nous attendons un retour sur investissement en moins de deux trimestres. Chacune supprime une tâche manuelle ou une erreur de reporting qui coûte déjà de l'argent, et chacune est un préalable à toute fonctionnalité d'IA qui exploitera plus tard les mêmes enregistrements.

Tout usage en aval repose sur des jointures. Le chiffre d'affaires par client exige que le système de commandes et le grand livre partagent une clé client. La marge par produit exige que la boutique, l'entrepôt et le grand livre des achats s'accordent sur ce que désigne une référence produit. Un assistant d'IA qui répond à des questions sur les commandes ou les produits hérite de toutes les ambiguïtés que portent ces clés.

Le contrôle est rapide. Pour chaque identifiant, vérifiez qu'il est renseigné et qu'il est unique sur l'ensemble de la population, de sorte qu'un code corresponde à un seul produit. Ce sont deux tests distincts. Un champ de référence produit peut être rempli sur chaque enregistrement et pourtant partagé par deux articles différents, ce qui suffit pour qu'un assistant décrive le mauvais produit avec une parfaite assurance, ou pour qu'un catalogue envoyé à un partenaire commercial présente le mauvais article sous le bon code.

Le retour vient du travail que la correction supprime : les avoirs émis pour des expéditions erronées, les heures passées à rapprocher les relevés clients, et les rapports reconstruits à la main chaque mois parce que deux systèmes divergent.

Les propriétés standard de Google Analytics 4 conservent les données au niveau des utilisateurs et des événements pendant 2 mois par défaut et 14 mois au maximum ; une conservation plus longue des données d'événements n'est possible qu'avec la version payante 360. Les rapports standard reposent sur des tables agrégées et continuent d'afficher les totaux anciens, si bien que la perte reste invisible jusqu'à ce que quelqu'un construise une exploration ou un entonnoir d'une année sur l'autre et trouve la période antérieure vide. Augmenter la durée de conservation ne protège que les données qui n'ont pas encore été supprimées.

La solution durable est l'export vers BigQuery, qui copie les événements bruts dans un entrepôt de données appartenant à l'entreprise. Les propriétés standard peuvent envoyer jusqu'à 1 million d'événements par jour via l'export quotidien. L'export en continu n'a pas de limite de volume et coûte 0,05 $ par gigaoctet, soit environ 600 000 événements selon Google. À ces tarifs, la facture de stockage d'une entreprise de taille moyenne est modeste au regard du coût d'une haute saison planifiée sans les données comportementales de l'année précédente.

Cette correction porte en elle son échéance. Chaque mois d'attente est un mois d'historique d'événements irrécupérable, et le cycle de planification 2027 aura besoin de l'intégralité de la haute saison 2026.

La facturation électronique fait des données de référence clients une condition de conformité. En Allemagne, les entreprises dont le chiffre d'affaires de l'exercice précédent dépassait 800 000 € doivent émettre leurs factures nationales entre entreprises dans un format électronique structuré à compter du 1er janvier 2027, toutes les autres entreprises suivant à compter du 1er janvier 2028 ; leur réception est obligatoire depuis le 1er janvier 2025. Au Royaume-Uni, le gouvernement a indiqué que toutes les factures soumises à la TVA devront être électroniques à partir d'avril 2029, a confirmé Peppol comme réseau d'échange et annoncé qu'une feuille de route détaillée de mise en œuvre accompagnerait le budget 2026, attendu le 28 octobre.

Le travail rentable est le même dans les deux pays et commence bien avant toute échéance. Complétez et validez les numéros de TVA, les identifiants fiscaux et les adresses de routage électronique dans le fichier de référence clients. Normalisez les codes produits et les codes de taxe sur les lignes de facture. Supprimez les étapes manuelles entre le système de commandes et la facture. Une facture rejetée retarde l'encaissement : des données de référence propres raccourcissent donc le recouvrement tout en satisfaisant à la règle, et un modèle de données construit ce trimestre pour une entité allemande pourra être réutilisé plus tard pour le Royaume-Uni.

La dernière correction relève davantage de la discipline que du système. Les rapports de gestion tirent le chiffre d'affaires de la boutique ou du CRM, les coûts du grand livre et les résultats marketing des plateformes publicitaires, et les trois concordent rarement. Lorsque le dossier du conseil et les comptes divergent d'un montant que personne ne sait expliquer, chaque chiffre du dossier perd son autorité, et les décisions ralentissent pendant que l'on débat du bon chiffre.

Un tableau de passage mensuel règle la question. Après la clôture, chaque chiffre clé du pack de reporting de gestion est rapproché du grand livre, l'écart étant décomposé en éléments récurrents et nommés : décalages temporels, remboursements, taxes, opérations intragroupe, commandes de test. Le tableau de passage est généré à partir des systèmes plutôt qu'assemblé à la main, et tout résidu inexpliqué supérieur à un seuil convenu est analysé avant la diffusion du pack. Une fois les éléments récurrents nommés, ce qui reste se résume généralement à une courte liste de processus que personne n'avait documentés.

C'est aussi la fondation dont aura besoin tout assistant de reporting fondé sur l'IA. Un modèle à qui l'on demande pourquoi la marge a baissé dans une région ne peut répondre correctement que si les chiffres qu'il lit ont déjà été rapprochés. Nous construisons ces tableaux de passage en partant du grand livre, pour la même raison que nous commençons chaque mission par les commandes, les grands livres et les journaux : un tableau de bord ne vaut que par les enregistrements qui le sous-tendent.

En novembre 2026, retracez un échantillon de commandes, de factures et de mouvements de stock réels dans tous les systèmes, et listez chaque point où un enregistrement est ressaisi, copié ou doté d'un nouvel identifiant.

Avant la fin novembre, réglez la conservation des événements GA4 sur 14 mois dans chaque propriété et associez chaque propriété à BigQuery, afin de conserver l'intégralité de la haute saison 2026.

D'ici fin décembre, vérifiez l'unicité et la complétude des identifiants clients, produits et commandes dans tous les systèmes, et corrigez les références produits en double avant qu'une fonctionnalité d'IA ou un catalogue professionnel ne s'appuie sur elles.

Pour toute entité allemande, vérifiez avant le 1er janvier 2027 si elle dépasse le seuil de 800 000 € et si sa facturation et ses données de référence clients sont prêtes, puis planifiez l'obligation britannique sur le même modèle de données une fois la feuille de route publiée.

À partir de la clôture de janvier 2027, publiez chaque mois un tableau de passage du pack de reporting de gestion au grand livre, avec des éléments de rapprochement nommés et un seuil de résidu.

D'ici juin 2027, choisissez le premier cas d'usage de l'IA à partir des données rapprochées et mesurez sa situation de référence à partir des mêmes enregistrements.