La plupart des workflows courants pour les analystes suivent le même schéma : extraire des données d'une source, les nettoyer, les combiner à d'autres données, appliquer une logique métier, puis générer un résultat. Le résultat est enregistré dans un rapport, une table Snowflake ou un e-mail, et le processus se répète la semaine suivante. Sauf si la personne qui l'a conçu est absente.
La plupart des entreprises partent du principe que l'automatisation de ce type de tâches nécessite Python ou SQL, et qu'il s'agit d'une question technique. Ce n'est pas le cas. Le problème, c'est que la logique contenue dans la feuille de calcul, et dans l'esprit de l'analyste qui l'a créée, n'a jamais trouvé son emplacement définitif. Cet article explique comment en mettre un en place sans avoir à écrire de code.
Si votre équipe dispose d'un rapport qui suit chaque semaine les mêmes étapes manuelles (mêmes sources, même logique, même résultat), gardez ce workflow à l'esprit tout au long de votre lecture.
Pourquoi les workflows manuels de traitement des données continuent de poser problème, et pourquoi l'augmentation du nombre d'outils n'est pas la solution
Il convient de faire une distinction utile avant de diagnostiquer le problème. La logique métier est présente dans les règles de configuration ERP, les déclencheurs de workflows, ou encore les champs calculés de BI. Les organisations intègrent un volume considérable de logique dans leurs systèmes. Ce qui est rarement pris en compte, c'est la couche supérieure : l'interprétation propre à l'analyste qui rend les données réellement exploitables pour un rapport ou une décision donnée.
Cette couche inclut différentes choses : la règle de rapprochement qui considère un écart de 3 % comme acceptable, sauf si le compte se trouve dans une région spécifique, la liste des exceptions pour les clients dont les identifiants sont formatés différemment d'un système à l'autre, ou encore la décision discrétionnaire concernant la méthode de comptabilisation des produits à appliquer lorsqu'une transaction est conclue au cours de la dernière semaine d'un trimestre. Il ne s'agit pas ici de logique métier au sens de la configuration du système. C'est ce qu'on appelle le savoir institutionnel : l'accumulation des décisions prises au fil des mois ou des années par des analystes qui connaissaient suffisamment bien l'activité pour savoir ce que les données brutes ne pouvaient pas révéler à elles seules.
Ces connaissances se trouvent dans les formules des feuilles de calcul, dans les tables de correspondance et dans l'esprit de ceux qui ont mis en place ce processus. Il n'est jamais documenté de manière systématique, ce qui signifie qu'il n'est jamais maintenu de manière systématique. Chaque modification en amont, qu'il s'agisse d'un champ Salesforce renommé, d'un nouveau centre de coûts ou d'une restructuration des territoires, doit être repérée manuellement à chaque emplacement où cette logique a été appliquée manuellement.
Les défaillances les plus fréquentes
Le problème du transfert de connaissances. Lorsque l'analyste responsable d'un workflow critique quitte l'entreprise ou change de poste, le processus s'arrête ou est entièrement reconstruit. La refonte prend généralement plusieurs semaines, et la version remaniée comporte de légères inexactitudes que personne ne remarque avant que les chiffres ne soient présentés lors d'une réunion du conseil d'administration. Il ne s'agit pas d'un problème humain. C'est ce qui se produit lorsque le savoir institutionnel ne repose que sur la mémoire d'une seule personne.
Le problème des pannes silencieuses. Un système en amont ajoute une colonne, modifie le nom d'un champ ou adapte le format d'un identifiant. La fonction VLOOKUP fait référence à la mauvaise colonne. Le résultat semble toujours complet. Personne ne remarque rien pendant deux cycles de reporting. Au moment où l'erreur est détectée, deux mois de données sont concernés et la correction nécessite de remonter le fil d'un processus non documenté pour comprendre ce qui s'est passé. Cette faille n'a pas été introduite par la nouvelle modification en amont : elle existait déjà.
La limite de l'échelle. Le processus s'applique au volume de données actuel et à l'ensemble de rapports actuel. Puis l'entreprise se développe, ajoute de nouvelles gammes de produits ou acquiert une autre entité. Les processus manuels ne sont pas évolutifs : ils se fragmentent en versions légèrement différentes, gérées par des personnes différentes, ce qui donne lieu à des chiffres légèrement différents, que l'on découvre au pire moment possible.
Les outils de BI ont besoin de données propres et structurées en entrée, ils ne les génèrent pas eux-mêmes. Les pipelines ETL fonctionnent au niveau des schémas et sont conçus pour les ingénieurs, et non pour mettre en œuvre la logique métier décrite ci-dessus, qui repose largement sur des décisions subjectives. Python et dbt comblent cette lacune pour les équipes d'ingénieurs, mais transfèrent la responsabilité de la logique de l'analyste, qui la comprend, vers l'ingénieur, qui assure la maintenance du script. Il manque une couche dans laquelle la logique métier pourrait être codée une seule fois, gérée par les personnes qui en sont responsables, et exécutée de manière fiable sans intervention. C'est précisément ce pourquoi l'automatisation de workflow est conçue.
Python, Power Automate ou no-code : comparaison objective
Le choix de l'outil approprié dépend de qui doit être responsable de la logique et de la fréquence à laquelle celle-ci évolue.
Python + dbt est le choix idéal lorsque la logique de transformation est suffisamment complexe pour justifier une gestion des versions et que l'équipe dispose des ressources nécessaires pour en assurer la maintenance.
Power Automate gère efficacement le routage entre applications au sein de l'écosystème Microsoft, mais n'est pas conçu pour la préparation analytique en plusieurs étapes des données entre des systèmes dont les schémas ne correspondent pas.
Un pipeline géré par des ingénieurs est pertinent lorsque le traitement porte sur des volumes importants, que le schéma est stable et qu'il est peu probable que des modifications des règles métier soient nécessaires.
L'automatisation de workflow en no-code est la solution idéale lorsque la logique appartient aux analystes, lorsque le workflow doit être compris et modifié par les métiers, et lorsque la rapidité d'itération est essentielle.
Constat objectif : à qui faire appel lorsque les règles métier changent ? Si la réponse est « un analyste », le workflow doit être dans un outil que l'analyste peut maintenir.
Comment automatiser un workflow de données sans écrire de code : guide détaillé
Les étapes suivantes fonctionnent avec n'importe quelle plateforme d'automatisation de workflow no-code. Elles sont prévues pour un analyste senior qui maîtrise les données et la problématique métier, et qui souhaite mettre en place un premier workflow automatisé sans faire appel à l'équipe d'ingénierie.
Étape 1 : choisissez le bon workflow pour commencer
Tous les workflows n'ont pas forcément besoin d'être automatisés en priorité. Le meilleur candidat de départ présente trois caractéristiques : il s'exécute selon un calendrier fixe ou un déclencheur régulier, il produit le même type de résultat à chaque fois, et la personne qui en est responsable est également celle qui en comprend la logique métier.
Conseil pratique : jetez un œil aux trois derniers mois de votre calendrier. Y a-t-il des notes du type « mettre à jour le rapport », « extraire les chiffres » ou « lancer le rapport hebdomadaire » ? Si oui, alors voilà votre premier candidat, ou plus précisément celui pour lequel vous vous êtes dit « J'ai déjà fait exactement la même chose 50 fois. »
Évitez de commencer par vos workflows les plus complexes. Commencez par quelque chose de prévisible. L'objectif de cette première automatisation est de créer un modèle fonctionnel que vous maîtrisez de bout en bout, et non de résoudre votre problématique la plus complexe.
Étape 2 : notez chaque étape avant de toucher à un outil
C'est l'étape que la plupart des analystes négligent, et c'est la raison pour laquelle les premières tentatives d'automatisation échouent. Avant d'ouvrir une plateforme, écrivez le processus depuis la première source de données jusqu'au résultat final. Pas de manière résumée, mais chaque étape.
Format pratique : source, action, résultat. Pour chaque étape, indiquez de quel système ou fichier proviennent les données, ce que vous leur faites subir (filtre, combinaison, calcule, nettoyage, mise en forme) et quel est le résultat. Si vous effectuez une jointure entre deux tables, indiquez la clé de jointure et notez toute divergence connue. Si vous appliquez une formule, écrivez la formule. S'il existe des exceptions (des comptes traités différemment, des plages de dates soumises à une logique différente, ou tout autre élément que vous gérez dans une table de correspondance), indiquez-les clairement.
La plupart des analystes estiment que cela prend entre 45 et 90 minutes et donne lieu à un document plus long que prévu. Un processus qui nécessite 90 minutes pour être documenté et 2 heures pour être exécuté chaque semaine est un excellent candidat à l'automatisation. Un processus difficile à documenter pour raison de « ça dépend » vous indique que la logique n'est pas encore assez stable.
Étape 3 : déterminez quelles logiques reposent sur des règles et lesquelles nécessitent un jugement
C'est cette distinction qui détermine ce que vous pouvez automatiser et ce qui nécessite l'intervention d'un être humain.
La logique basée sur des règles fournit une réponse fixe et reproductible, quel que soit le contexte : effectuer une jointure en fonction de telle clé, marquer les lignes dont l'écart dépasse 5 %, filtrer les lignes avec un statut particulier, appliquer telle conversion de devise. Tout cela se traduit directement en une étape de workflow.
La logique fondée sur le jugement désigne tout ce qui repose sur le fait que la bonne réponse se trouve dans votre esprit plutôt que dans une condition prédéfinie. Exemples courants : « ces trois comptes doivent toujours faire l'objet d'une vérification manuelle, car leurs identifiants ne correspondent jamais parfaitement », « ce champ de chiffre d'affaires a une signification différente au quatrième trimestre », ou « le seuil est de 5 % sauf pour les comptes d'entreprise, pour lesquels nous utilisons 8 % ». La documentation des processus de l'étape 2 mettra ces points en évidence : il s'agit généralement d'étapes que vous avez notées comme étant à vérifier manuellement, ou que vous n'avez pas pu décrire sans préciser que ça dépend.
Le but n'est pas d'éliminer tout jugement, mais de le rendre explicite. Pour chaque étape qui repose sur un jugement, posez-vous la question suivante : quelle est la règle que j'applique réellement, même si je ne l'ai jamais mise par écrit ? La plupart du temps, vous pouvez y répondre. Une fois défini, ce point devient un paramètre configurable ou une table de correspondance dans laquelle votre workflow lit les informations, plutôt qu'une décision que vous prenez manuellement à chaque cycle. La liste des comptes d'exception figurant dans la colonne de votre feuille de calcul devient un fichier de référence autonome que le workflow lit. Un seuil présent dans votre mémoire devient un paramètre nommé en haut du workflow, accompagné d'une note expliquant son origine.
Étape 4 : Décrivez votre connexion aux données et la manière dont vous y accédez actuellement
Avant de choisir une plateforme, dressez la liste de tous les systèmes auxquels votre workflow a accès et, surtout, précisez comment vous extrayez actuellement les données de chacun d'entre eux. Classez chaque source dans l'une des trois catégories suivantes : vous générez un rapport dans le système et téléchargez un fichier, vous recevez un fichier exporté par e-mail de la part d'une autre personne, ou vous interrogez directement le système via SQL ou une API.
Cette classification est importante car elle met en évidence ce que le connecteur d'une plateforme doit réellement remplacer. Une source de catégorie 1 ou 2 signifie que vous devez actuellement effectuer une étape de récupération manuelle. Une plateforme qui se présente comme connectée à Salesforce mais qui vous oblige tout de même à créer un rapport Salesforce et à récupérer le fichier n'a pas supprimé cette étape ; elle l'a simplement déplacée. Ce qu'il vous faut pour ces sources, c'est une connexion en temps réel qui récupère les données actuelles à chaque exécution, sans passer par une exportation intermédiaire. Vérifiez tout cela avant de passer à la conception.
Cette étape soulève également des questions relatives à l'accès aux données (identifiants, autorisations, règles de pare-feu), qu'il est bien plus facile de régler avant de commencer le développement qu'ensuite.
Étape 5 : développez la première version par étapes, et non d'un seul coup
Une fois que vous disposez de votre documentation, que votre logique est classée et que vos connexions sont cartographiées, vous êtes prêt à passer à la phase de développement. Le principe : faire en sorte que le résultat obtenu à chaque étape est correct et vérifiable avant de passer à l'étape suivante.
La première étape correspond simplement à votre première source et à votre premier filtre, ou à votre première étape de nettoyage. Connectez-vous à la source, appliquez uniquement la logique que vous utiliseriez en premier lieu dans votre processus manuel, puis exportez le résultat vers un aperçu ou un fichier plat. Comparez le nombre de lignes et un échantillon d'enregistrements avec les résultats de votre processus manuel pour la même période. Ils doivent correspondre. Si ce n'est pas le cas, cela signifie que vous rencontrez un problème de connexion ou de filtrage, que vous devez résoudre avant de continuer.
Ajoutez ensuite l'étape suivante. S'il s'agit d'une jointure, c'est là que vous passerez le plus de temps. Vérifiez le taux de correspondance. Si votre processus manuel affiche un taux de correspondance de 94 %, la version automatisée devrait en faire de même. Si ce n'est pas le cas, la logique de mise en correspondance n'est pas encore équivalente. Les causes les plus courantes sont des problèmes de zéros, des incohérences dans le format de la date, ou encore des variations dans l'usage de la casse. Commencez par résoudre la normalisation des identifiants, vérifiez le taux de correspondance, puis passez aux étapes suivantes.
Suivez chaque étape dans l'ordre. Cette approche peut sembler plus lente que de construire le workflow dans son intégralité d'un seul coup, mais elle facilite le débogage. Lorsque les résultats ne correspondent pas, vous savez exactement à quelle étape la divergence a été introduite.
Étape 6 : Exécutez-le manuellement trois fois avant de le programmer
Avant de programmer un workflow, exécutez-le manuellement sur trois ensembles de données différents : les données de la semaine passée, celles d'une semaine datant d'il y a 2 mois, et celles d'une semaine où un événement inhabituel s'est produit (une fin de trimestre, un changement de territoire, la finalisation d'une acquisition). Comparez le résultat généré automatiquement à celui obtenu manuellement pour chacun.
Cela met en évidence les hypothèses que vous avez correctement intégrées dans votre esprit, mais que vous avez mal transcrites dans le workflow. Exemples courants : des filtres de date qui fonctionnent pour la semaine en cours mais qui échouent lorsque la limite du mois change, une logique de jointure qui traite correctement la plupart des enregistrements mais qui gère mal une catégorie d'exception spécifique, et une mise en forme d'output qui ne fonctionne plus en présence de valeurs nulles ou de longueurs de champ inattendues.
Dès lors que le workflow produit des résultats identiques lors des trois exécutions de test, la logique est validée. Définissez la planification. À ce stade, la première automatisation est en place — tout comme le processus manuel qu'elle a remplacé.
Trois critères pour distinguer les plateformes dignes d'évaluation des autres
Le marché des outils data no-code et low-code s'est tellement développé qu'il existe désormais de nombreuses options qui semblent similaires en démonstration. Les critères suivants ont tendance à mettre en évidence de réelles différences lorsqu'on passe à la pratique.
Connexion aux données en temps réel ou dépendante d'une exportation
La principale source de frustration lors des premières tentatives d'automatisation réside souvent dans le fait de découvrir que le connecteur Salesforce de la plateforme vous oblige à planifier l'exportation d'un rapport Salesforce, puis à récupérer le fichier, ce qui signifie que vous avez automatisé le traitement des données, mais pas leur récupération. L'étape manuelle qui prend le plus de temps reste souvent manuelle.
Demandez précisément si la plateforme se connecte directement au système source et récupère les données actuelles à chaque exécution de workflow. Est-il possible d'exécuter des requêtes directement dans la base de données d'un entrepôt de données dans le cloud, tel que Snowflake ou Databricks, sans avoir à transférer au préalable les données vers la plateforme ? Les réponses déterminent si vous pouvez réellement supprimer l'étape d'exportation ou simplement la déplacer.
Logique vérifiée par une personne autre que celle qui l'a élaborée
L'un des principaux problèmes liés aux workflows manuels est que leur logique n'est connue que de la personne qui les a mis en place. Une plateforme qui remplace une feuille de calcul par un workflow tout aussi opaque n'a pas résolu le problème : elle l'a simplement déplacé.
Ce que vous recherchez : un workflow où chaque étape de la transformation est visible, identifiée et compréhensible par toute personne ayant accès au système. Des journaux d'audit qui enregistrent les opérations exécutées, la date d'exécution et les inputs utilisés. Un historique des versions qui vous permet de voir ce qui a changé d'une exécution à l'autre. Ce ne sont pas des éléments facultatifs : c'est ce qui fait la différence entre un workflow que votre organisation gère et un workflow qu'un analyste gère seul.
Mise à jour de la logique lorsque le contexte métier évolue
C'est le critère sur lequel la plupart des plateformes peinent à grande échelle. Un workflow intégré à un outil qui nécessite l'envoi d'une demande d'assistance à l'ingénierie pour mettre à jour un paramètre ne peut pas être géré par un analyste. Cela revient simplement à automatiser la dépendance plutôt qu'à la supprimer.
Le test : choisissez une règle métier qui évolue régulièrement dans votre travail. Un seuil, une cartographie du territoire, une liste des comptes faisant l'objet d'une exception. Sur une plateforme donnée, comment mettriez-vous à jour cette règle six mois après la création du workflow, si la personne qui l'a créé avait quitté l'équipe ? Si la réponse nécessite d'ouvrir un fichier de code ou de créer une demande d'assistance, le modèle de gouvernance n'est pas adapté à la logique gérée par les analystes.
Six étapes pour l'automatisation du rapprochement des recettes
Le processus de rapprochement des recettes présenté ci-dessous a été développé dans Alteryx One, mais toute plateforme répondant aux trois critères énoncés dans la section précédente fonctionnerait de la même manière.
Version manuelle
Chaque lundi, un analyste RevOps exporte depuis Salesforce les opportunités avec contrat conclu de la semaine précédente au format CSV, et reçoit par e-mail un extrait des factures du système ERP Oracle transmis par le service financier. Ces deux fichiers sont intégrés dans une feuille de calcul de rapprochement principale qui a été traitée par trois analystes au cours des deux dernières années. La version actuelle est un mélange de la structure d'origine et de deux séries de modifications apportées par ceux qui ont dû corriger certains éléments.
La fonction VLOOKUP permet de faire correspondre des enregistrements en fonction de l'ID d'opportunité. Le taux de correspondance avoisine les 94 % les bonnes semaines. Les 6 % restants sont classés dans la colonne « Vérification manuelle », principalement parce que Salesforce stocke les identifiants d'opportunité avec un zéro en tête, qu'Oracle supprime lors de l'exportation. L'analyste tient à jour une table de correspondance dans la colonne AC, qui répertorie les divergences connues. Les nouvelles sont ajoutées au fur et à mesure qu'elles sont détectées.
Le seuil de variance de 5 % utilisé pour signaler les divergences a été défini par l'analyste qui a élaboré la version initiale. L'analyste actuel connaît le chiffre, mais pas le raisonnement qui le sous-tend. Il n'est documenté nulle part.
Durée totale pour une semaine sans imprévus : entre 2 h 30 et 3 h. Si une exportation échoue ou si une nouvelle colonne apparaît dans le rapport Salesforce, il faut prévoir une heure supplémentaire pour le débogage.
Limitations
Une réorganisation en milieu d'année entraîne le transfert de 40 comptes d'un territoire à un autre. Le champ de territoire dans Salesforce contient désormais des valeurs qui ne correspondent pas aux codes de segment de grand livre correspondants dans Oracle. La fonction VLOOKUP fonctionne toujours, mais elle effectue la correspondance sur une base erronée pour ces 40 comptes. Le résultat semble correct. Les recettes des comptes concernés ont été affectées au mauvais segment pendant deux cycles de reporting avant qu'un membre de l'équipe FP&A ne remarque que les chiffres régionaux ne concordaient pas.
Dans le cadre de l'enquête, l'analyste responsable du rapport doit reconstituer oralement le raisonnement pour expliquer ce qui n'a pas fonctionné. Le problème n'est pas d'avoir commis une erreur, mais que la logique de rapprochement reposait sur une hypothèse structurelle concernant la mise en correspondance entre les territoires et les segments, qui n'avait jamais été formalisée en règle. Elle n'était écrite nulle part.
Fonctionnement du workflow après automatisation
L'étape 1 a permis d'identifier cette solution comme un premier candidat sérieux : cadence hebdomadaire fixe, format de sortie homogène, et un seul responsable qui maîtrise également la logique métier. L'étape 2 a permis de documenter le processus, y compris le problème de non-correspondance des identifiants et la table de recherche des exceptions. À l'étape 3, le seuil de variance et la mise en correspondance entre territoire et segment ont été classés comme des éléments de logique dépendant d'un jugement qui devaient être explicités. Ces deux éléments sont ainsi devenus des paramètres nommés. L'étape 4 a permis de confirmer qu'Alteryx Designer dispose de connecteurs en temps réel vers Salesforce et Oracle, qui récupèrent les données actuelles sans nécessiter d'exporter des fichiers.
Le workflow intégré se connecte directement à Salesforce et à Oracle via des connecteurs natifs. L'étape de normalisation des identifiants gère le décalage des zéros initiaux comme une transformation configurée. La correspondance entre les territoires et les segments est définie dans une table de correspondance gérée au sein du workflow, dont la version est mise à jour à chaque modification. Le seuil de variance de 5 % est un paramètre nommé situé en haut du workflow : il est visible, accompagné d'une note expliquant son origine, et peut être modifié par tout analyste disposant des droits d'accès nécessaires. Les données sont transmises à Snowflake et déclenchent l'envoi d'un e-mail à la liste de diffusion. L'exécution est programmée le lundi à 7 h.
Lorsque la réorganisation a lieu, l'analyste met à jour la table de correspondance entre les territoires et les segments. Temps nécessaire : 15 mn. Le workflow fonctionne correctement lundi. Lorsque l'équipe FP&A demande pourquoi les attributions de segments ont changé, la réponse se trouve dans le journal des modifications horodaté du workflow, et non dans une reconstitution verbale.
L'étape 6 (trois tests avant la planification) a permis de détecter un problème : le filtre de date utilisait une logique « 7 derniers jours » qui donnait des résultats différents entre le lundi et le mardi en raison de la manière dont l'exportation Salesforce horodate les transactions conclues le dimanche soir. Le problème a été corrigé pendant la phase de test plutôt que découvert en production.
Le workflow ci-dessus illustre ce à quoi ressemble concrètement une première automatisation. Si vous souhaitez tester la même approche avec votre propre processus, Alteryx One propose un essai gratuit qui ne nécessite aucune configuration par l'IT pour démarrer.
Par où commencer : un workflow identifié comme défaillant
Les six étapes ci-dessus sont particulièrement efficaces lorsqu'elles sont appliquées à un processus que vous avez déjà identifié comme défaillant. Ce n'est pas la tâche la plus complexe que votre équipe accomplit, mais bien la plus fastidieuse. Celle où, à la question « Que se passerait-il si vous étiez absent pendant deux semaines ? », la réponse est : « Quelqu'un le referait entièrement de zéro, et le résultat serait légèrement faux. »
Trois questions pour déterminer votre premier workflow : quel processus prend le plus de temps à se reconstruire lorsqu'un changement survient en amont ? Lequel dépend le plus de la mémoire qu'une personne a de son fonctionnement ? Lequel a généré un résultat erroné, sans que personne ne s'en aperçoive avant qu'il ne soit trop tard pour y remédier proprement ? Le workflow qui obtient les pires scores sur ces trois critères est celui qu'il faut automatiser en premier.
Suivez les instructions de la documentation avant d'ouvrir un outil. Cette étape, qui consiste à consigner par écrit chaque action entre la source initiale et le résultat final, permet généralement de constater que le processus est soit plus rapide à automatiser que prévu, soit plus fragile qu'imaginé. Il est utile de connaître les deux.
Si vous vous demandez si Alteryx One est la plateforme qui convient à ce projet, l'essai gratuit est le moyen le plus simple de la tester avec vos propres données et vos propres processus. Il n'est pas nécessaire de faire appel à l'équipe IT pour lancer l'essai, et le workflow que vous avez documenté à l'étape 2 constitue déjà un cahier des charges prêt à l'emploi pour votre première conception.
Si la priorité actuelle est de renforcer la cohésion interne plutôt que de mener un projet pilote, l'évaluation de la maturité analytique d'Alteryx fournit un rapport chiffré, avec comparaison avec les autres entreprises du secteur. C'est utile pour mener une réflexion sur l'analyse de rentabilité et déterminer où les investissements dans l'automatisation sont les plus susceptibles de générer des retours mesurables.