La plupart des environnements analytiques à remplacer étaient suffisamment efficaces au départ. Mais ils se dégradent au fil du temps, avec une quatrième équipe qui demande l'accès, un système source qui change et la préparation des données qui passait inaperçue la première année devient la source de problèmes récurrents.
C'est à ce moment-là qu'une comparaison d'outils de Business Intelligence commence sérieusement. Non pas au début d'un parcours analytique, mais quelque part au milieu, quand la question n'est plus de savoir si ça fonctionne, mais si on peut passer à l'échelle sans alourdir d'autant la maintenance.
Cet article propose un cadre pour mener cette évaluation. Il explique pourquoi la complexité de la BI augmente avec le passage à l'échelle, quels critères permettent de distinguer les architectures robustes de celles qui ne tiennent pas dans la durée, propose une comparaison des workflows et présente une méthode pratique pour tester une plateforme avant de faire un choix. Alteryx One est la plateforme utilisée pour l'exemple de workflow, mais les sections avant la preuve de concept finale s'appliquent à n'importe quelle plateforme de votre liste.
Avant de lancer une évaluation formelle : choisissez le rapport que votre équipe recrée le plus souvent et détaillez toutes les étapes nécessaires pour le produire. La liste des transmissions manuelles, des transformations non documentées et des dépendances à une seule personne est généralement plus longue qu'on ne le pense. Cette cartographie constitue le point de départ le plus honnête pour comparer des plateformes.
D'où vient la complexité de la BI, et pourquoi elle s'accumule
Les outils BI traditionnels sont conçus pour la couche de restitution. Ils fonctionnent bien pour visualiser des données déjà nettoyées et structurées. Mais ils reposent sur une hypothèse implicite : que les données qui les alimentent sont déjà prêtes. Et c'est précisément de cette hypothèse que provient la complexité.
Lorsqu'une équipe ajoute une nouvelle source de données, quelqu'un doit la préparer avant que la plateforme BI puisse l'exploiter. Ce travail s'effectue quelque part: dans un script SQL sur l'ordinateur d'un collaborateur, dans un fichier Excel géré par un seul analyste, dans un notebook Python qui n'a pas été utilisé depuis huit mois. La plateforme BI ne perçoit pas ce travail, de sorte qu'il est invisible pour la gouvernance, et pour quiconque prend la relève lorsque cet analyste part.
La complexité s'accumule à trois stades spécifiques.
Préparation des données en amont
Le travail consistant à rendre les données exploitables par la couche BI, c'est-à-dire alignement des schémas, nettoyage, enrichissement, jointures entre sources, se fait entièrement en dehors de la plateforme BI. Il n'existe a pas de piste d'audit. Lorsque la source change, la dégradation passe inaperçue jusqu'à ce que quelqu'un remarque qu'un nombre est incorrect.
La dernière étape de la livraison des insights
Les tableaux de bord statiques répondent aux questions pour lesquelles ils ont été conçus. Lorsqu'un utilisateur métier a besoin de comprendre pourquoi un chiffre a changé, et pas seulement qu'il a changé, il soumet une demande ou tente de trouver la réponse à l'aide d'un outil qui n'a pas été conçu pour cela. Ces deux approches entraînent des retards, et l'équipe analytique devient un goulet d'étranglement précisément au moment où l'agilité est requise.
Tentatives isolées de montée en charge
Ajouter une nouvelle équipe ou un nouveau cas d'usage dans un environnement BI traditionnel se traduit généralement par plus de tableaux de bord, plus de pipelines et davantage de travail de préparation des données en amont, sans gouvernance commune. Chaque ajout est isolé du reste : pas de logique commune, pas de transformations réutilisables, pas de lignage commun. Le travail de maintenance augmente plus rapidement que les capacités de l'équipe.
Un cadre agnostique pour évaluer les plateformes analytiques à l'échelle
Deux schémas permettent généralement de distinguer les plateformes qui passent à l'échelle de celles qui atteignent leurs limites. Le premier concerne la répartition des responsabilités. Les plateformes qui couvrent l'intégralité du cycle de vie, de l'ingestion des données à la mise à disposition, permettent de contenir la complexité dans un environnement contrôlé. À l'inverse, les plateformes qui gèrent uniquement la couche de restitution laissent tout ce qui se trouve en amont à la charge des équipes.
Le second concerne la manière dont la plateforme gère l'accès pour les utilisateurs non techniques. Une plateforme qui nécessite l'intervention de développeurs pour chaque nouvelle source de données ou modification de workflow ne supprime pas un goulet d'étranglement, elle le déplace. Le test consiste à vérifier si un analyste métier peut créer et exécuter un workflow analytique dans un cadre de gouvernance défini sans avoir à soumettre de demande.
Les critères ci-dessous s'appliquent quelle que soit la plateforme figurant sur votre liste de solutions sélectionnées. Ils sont présentés sous forme de questions, car les échanges les plus utiles consistent à confronter les réponses d'un fournisseur à un scénario concret, plutôt qu'à accepter une liste de fonctionnalités telle quelle.
| criterion | La question à poser | Pourquoi c'est déterminant pour le passage à l'échelle |
|---|---|---|
| Cycle de vie complet | Si un schéma source change, combien de systèmes doivent-ils être mis à jour, et par qui ? | Les plateformes qui couvrent tout le cycle de vie, de la préparation jusqu'à la mise à disposition, gardent la complexité au sein d'un seul environnement sous gouvernance. Celles qui se limitent à la visualisation laissent tout ce qui est en amont sans gouvernance. |
| Autonomie des métiers | Un analyste métier peut-il créer, exécuter et partager un workflow sans intervention de l'IT, dans le respect des contrôles d'accès définis ? | Chaque tâche nécessitant un développeur crée un backlog qui augmente linéairement avec la taille de l'équipe. La plateforme qui élimine cette dépendance permet de passer à l'échelle sans augmenter les effectifs. |
| Connectivité étendue | Que se passe-t-il lorsque vous avez besoin de données provenant d'une source qui ne figure pas dans la bibliothèque de connecteurs standard ? | Les connecteurs standard couvrent les cas standard. Mais à l'échelle, il y a toujours une source non standard. La réponse à cette question révèle la véritable limite de la plateforme. |
| Gouvernance à l'échelle | Pouvez-vous retracer n'importe quel nombre jusqu'à sa source et répondre à une question de conformité sans solliciter l'analyste qui a créé le workflow ? | Le lignage des données transforme une investigation de deux jours en une analyse de dix minutes. Les pistes d'audit font la différence entre un environnement conforme et un environnement auquel les auditeurs ne peuvent pas se fier. |
| Couche de gouvernance de l'IA | L'IA fonctionne-t-elle dans le même cadre de gouvernance que le reste de la plateforme, ou est-elle ajoutée comme une brique indépendante ? | L'IA amplifie la qualité des données existantes. Une couche d'IA bien contrôlée impose un état de préparation des données avant de générer des insights. À l'inverse, une IA non contrôlée produit des réponses convaincantes à partir d'entrées peu fiables. |
| Adéquation de l'architecture dans le temps | La même plateforme peut-elle répondre aux besoins d'une équipe de 5 personnes comme à ceux d'un déploiement à 500 utilisateurs sans nécessiter de replatforming ? | Une plateforme qui impose une migration à chaque étape de croissance double la complexité au pire moment. |
Quand les alternatives sont le bon choix
Les outils BI traditionnels, tels que Tableau, Power BI, Looker, sont adaptés lorsque le besoin principal est la visualisation interactive de données déjà nettoyées, centralisées et structurées de manière cohérente. Les entreprises disposant d'équipes solides d'ingénierie des données, qui prennent en charge la couche de préparation, et dont les utilisateurs métier se concentrent principalement sur l’exploration et la présentation des données plutôt que sur leur transformation, en tirent pleinement parti. Le problème de complexité apparaît lorsque ces conditions ne sont pas réunies.
Les approches privilégiant le code (Python avec dbt, pipelines basés sur SQL gérés par l'équipe d'ingénierie des données) sont pertinentes lorsque les workflows nécessitent une logique sur mesure qu'aucun outil visuel ne gère correctement, lorsque l'équipe est principalement technique ou lorsque les exigences de passage à l'échelle et de performance dépassent les capacités des plateformes visuelles. Mais chaque modification nécessite un développeur, et la couche d'interprétation propre aux analystes (règles de rapprochement, logique des exceptions, arbitrages) se retrouve encodée dans des scripts que les métiers ne peuvent ni lire ni gérer.
Les plateformes d'automatisation analytique unifiées sont un bon choix lorsque l'entreprise a besoin que les utilisateurs métier prennent en charge et gèrent la logique analytique, lorsque le travail de préparation est suffisamment complexe pour qu'une absence de gouvernance représente un risque, ou lorsque l'objectif est de réduire la dépendance à l'IT sans diminuer la gouvernance. Elles privilégient la durabilité à l'échelle plutôt que la flexibilité de développement.
Ce que change un workflow automatisé : comparaison directe
La comparaison ci-dessous a pour cadre Alteryx One. Toute plateforme qui répond aux critères du cycle de vie complet des responsabilités et de la gouvernance présentés plus haut serait en mesure de gérer ce workflow de manière similaire.
Le scénario :
Une équipe financière produit un rapport hebdomadaire sur les écarts. En entrée : Oracle (chiffres réels), Workday (effectifs) et un fichier de mise en correspondance Excel qu'un analyste met à jour chaque lundi avec les codes budgétaires. Le processus manuel existe depuis deux ans et se répartit entre trois analystes. Le fichier de mapping a été créé par le premier, largement modifié par le second et est aujourd'hui géré, tant bien que mal, par le troisième. Personne ne sait exactement quelle version du mapping des codes des départements est la bonne.
Avant et après l'automatisation :
| Processus manuel | Workflow automatisé | |
|---|---|---|
| Extraction de données | L'analyste exporte manuellement les données depuis Oracle et Workday tous les lundis. Les noms de fichier changent à chaque fois. | Se connecte directement à Oracle et Workday. S'exécute automatiquement, sans déclenchement manuel. Toute plateforme répondant aux critères de connectivité du cadre de référence pourrait en faire autant. |
| Logique de mapping | Fichier Excel géré par un seul analyste. Codes de département mis à jour manuellement, parfois avec plusieurs semaines de retard. | La logique de mappage est intégrée au workflow. Les divergences sont signalées dans les lignes, plutôt que résolues discrètement. |
| Détection des erreurs | L'analyste remarque un écart dans les chiffres régionaux. Il remonte à la source manuellement, et perd une matinée. | Une incohérence de schéma déclenche une alerte dans le workflow. Un analyste vérifie les lignes signalées en 15 minutes. |
| Livraison | Jeudi après-midi, avec deux jours de retard. Versions différentes déjà en circulation. | Mardi matin, à l'heure. Une seule version, traçable jusqu'à sa source. |
| Transfert de connaissances | Les règles de rapprochement existent uniquement dans la mémoire de l'analyste et dans six formules imbriquées. Elles ne sont documentées nulle part. | Chaque étape de transformation est visible dans le workflow. Un nouvel analyste peut lire, vérifier et modifier la logique sans avoir recours à la rétro-ingénierie. |
| Gouvernance | Pas de piste d'audit. Aucune information permettant de savoir quelles données ont été extraites, quand, par qui, ni ce qui a changé. | Les journaux d'audit enregistrent chaque exécution : qui l'a déclenchée, quand, quelles données sont concernées). Les questions de conformité sont traitées en quelques minutes. |
Le problème qui rend ce scénario spécifique plutôt que générique : un code de département mis à jour dans Oracle il y a six semaines n'a jamais été reporté dans le fichier de mappage Excel. La fonction RECHERCHEV continue de s'appuyer sur l'ancien code, sans aucune erreur ni alerte, et produit des nombres qui semblent corrects jusqu'à ce que quelqu'un détecte l'anomalie. Il faut une matinée pour comprendre, et quinze minutes pour corriger.
Avec l'approche automatisée, le problème est décelé et signalé à la prochaine exécution. L'analyste examine les problèmes signalés, met à jour les correspondances et relance l'exécution. Le rapport est diffusé mardi.
Le workflow ci-dessus a été conçu dans Alteryx One. Si vous êtes en phase d'évaluation et que vous créez un business case en parallèle de la comparaison des plateformes, l'outil Alteryx Évaluation de la maturité analytique fournit un score comparatif basé sur des entreprises comparables, ce qui constitue des éléments de preuve utiles pour les discussions IT et finance qui suivent généralement une présélection de plateformes.
Comment réaliser une preuve de concept pour tester le passage à l'échelle
La plupart des évaluations de plateformes reposent sur un scénario de démonstration fourni par l'éditeur. Ce scénario est optimisé pour fonctionner. En revanche, il ne teste généralement pas les points de défaillance propres à votre environnement, ceux qui apparaîtront après quelques mois : une source de données non standard, un changement de schéma, ou encore un second analyste devant modifier un workflow que le premier a mis en place.
Voici un protocole de test, directement aligné sur les critères du cadre de référence :
| Que tester | Comment tester | À quoi ressemble un résultat concluant |
|---|---|---|
| Responsabilité de la préparation en amont | Prenez un workflow réel qui se trouve actuellement dans Excel ou dans un script. Recréez-le à l'intérieur de la plateforme. Combien de temps cela prend-il ? Qui peut le faire ? | Un analyste métier, et non un développeur, peut recréer le workflow sans intervention de l'IT, et le résultat est auditable sans dépendre de la personne qui l'a initialement conçu. |
| Gestion des changements de schéma | Renommez intentionnellement une colonne dans les données source et relancez le workflow. Que se passe-t-il ? | La plateforme signale explicitement l'erreur (une erreur clairement identifiée, une ligne signalée) au lieu de renvoyer une réponse incorrecte sans aucune alerte. |
| Connectivité aux sources non standard | Identifiez une source de données de votre environnement qui ne soit pas une base de données Snowflake, Salesforce ou standard. Essayez de vous y connecter. | La connexion aboutit sans nécessiter de développement spécifique. Si une intervention technique est nécessaire, cette dépendance se répétera à chaque nouvelle connexion. |
| Audit de gouvernance | Exécutez le workflow, puis répondez à ces questions : qui l'a exécuté, quand, quelles données a-t-il utilisées et quelle version de la logique de transformation était active ? | Ces quatre questions peuvent trouver une réponse dans les journaux de la plateforme en moins de cinq minutes, sans avoir à interroger l'analyste. |
| Ajout d'un second utilisateur | Demandez à une personne autre que le créateur initial de modifier le workflow (ajuster une transformation, ajouter une source de données, modifier la planification). | Le second utilisateur effectue la modification selon son niveau d'accès, le changement est consigné et le workflow original reste accessible dans l'historique des versions. |
Deux de ces tests méritent une pondération plus importante que les autres pour cette évaluation spécifique. La gestion des changements de schéma est celui qui conduit le plus souvent à éliminer une plateforme, non pas parce qu'elle ne sait pas les gérer, mais parce que le mode de défaillance est silencieux. Une plateforme qui produit un résultat incorrect au lieu de signaler explicitement le problème générera des rapports erronés que personne ne remarquera à temps.
Le test d'ajout d'un second utilisateur révèle le véritable coût de maintenance au fil du temps. Un workflow que seul son créateur initial peut modifier n'a pas échappé au problème de dépendance à une seule personne. Il l'a simplement déplacé d'Excel vers un autre outil. La question de la gouvernance et celle du transfert de connaissances, évoquées dans le tableau comparatif, dépendent toutes deux de la réussite de ce test.
Effectuez les deux tests sur chaque plateforme de votre liste restreinte, en utilisant des données réelles de votre environnement. Les résultats seront bien plus révélateurs que les performances annoncées par les fournisseurs.
Par où commencer
Choisissez le rapport que votre équipe refait le plus souvent. Cartographiez les étapes : quelles sources de données sont utilisées, où se fait la préparation, qui est responsable de chaque étape, ce qui cesse de fonctionner lorsqu'une source en amont change. Deux ou trois étapes peuvent être automatisées immédiatement. Une ou deux nécessitent une décision de gouvernance concernant la responsabilité des connexions aux données ou de la logique de transformation. Mieux vaut s'intéresser à ces décisions assez tôt : elles émergent dans chaque évaluation et les plateformes qui les rendent visibles dès le départ offrent un niveau de confiance supérieur à celles qui les reportent à la mise en œuvre.
Partez d'un workflow. Concevez-le dans une plateforme de votre shortlist. Altérez intentionnellement les données source et observez ce qui se passe. C'est là que vous voyez la différence entre une plateforme qui alerte et une qui laisse passer l'erreur.
Commencez par un rapport que votre équipe refait déjà régulièrement. Créez le workflow à l'occasion d'un essai gratuit d'Alteryx One. Connectez-vous aux sources de données utilisées, définissez la logique de transformation et exécutez le test de changement de schéma sur vos propres données. L'objectif n'est pas de repenser tout l'environnement analytique, mais de comprendre ce qu'un workflow automatisé et contrôlé change concrètement dans le fonctionnement de l'équipe.