Chaque argumentaire en faveur de l'automatisation des workflows low-code met en avant la même chose : la vitesse. Des conceptions plus rapides, un déploiement plus rapide, tout plus rapide.
Il est vrai que la rapidité aide, mais ce n'est pas ce qui détermine si un workflow survit à sa première année. La question de la propriété est, plus précisément, de savoir qui détient la logique interne et ce qui se passe lorsque cette personne quitte l'équipe, est promue ou est simplement en vacances pour deux semaines. Un workflow qui s'exécute rapidement aujourd'hui mais qui n'existe que dans la tête d'une seule personne n'est pas automatisé. C'est rapide, mais pas durable, ce qui pose problème.
Cet écart entre la vitesse et la durabilité apparaît rarement lors d'une démonstration de produit, ce qui est compréhensible, car ce n'est pas vraiment un argument de vente pour un outil. En réalité, cela ne devient visible qu'au bout de huit mois environ, lorsque la personne qui a créé le workflow est absente ou partie, et que le rapport qu'il alimente doit toujours être rendu le lundi matin. À ce stade, personne ne se félicite de la rapidité avec laquelle il a été conçu à l'origine.
Cet article passe en revue cinq domaines où la vitesse et la durabilité divergent, en commençant par l'argument de la vitesse.
Pourquoi la vitesse n'est pas la seule raison pour laquelle le low-code est important
La rapidité est un avantage réel du low-code, certes, mais si vous en faites votre objectif, vous n'obtiendrez qu'une feuille de calcul plus rapide, et non un outil d'automatisation de workflow durable.
Les organisations misent sérieusement sur la rapidité, et les chiffres du marché le confirment. Gartner prévoit que le marché des technologies de développement low-code atteindra 58,2 milliards $ d'ici 2029, avec une croissance annuelle de 14,1 % à mesure que l'IA agentique et le développement citoyen stimulent l'adoption. Mais cela ne dit rien sur la fiabilité de ce qu'ils construisent.
Et c'est là que la différence entre adoption et durabilité prend toute son importance. Un workflow rapide à construire et facile à transmettre gagne en valeur chaque mois, car quelqu'un d'autre que le concepteur initial peut le reprendre et continuer à l'améliorer. Un workflow qui est simplement rapide à construire devient au contraire plus risqué chaque mois, car personne à part son auteur ne sait vraiment ce qui se passe à l'intérieur. C'est en confondant les deux que la plupart des stratégies marketing low-code font fausse route.
Par exemple, un analyste assemble quelque chose en un après-midi. Cela fonctionne, et gagne en poids. Six mois plus tard, personne d'autre ne peut y toucher sans risque. C'est un schéma qui se reproduit de la même manière dans toutes les équipes analytiques, et vous l'avez probablement déjà constaté par vous-même.
Rien de tout cela n'est un problème spécifique au low-code, mais la rapidité du low-code permet d'atteindre cet état plus facilement et avec moins de contrôle en cours de route qu'un processus codé manuellement.
Imaginez deux workflows créés la même semaine, résolvant tous deux le même problème. Le premier est construit rapidement et reste tout aussi rapide que le jour de sa mise en service, sans documentation ni propriétaire désigné autre que son auteur. C'est l'équivalent, pour un workflow, d'une porte sans inscription que personne ne veut ouvrir. Le second prend un peu plus de temps à terminer car il est construit avec une structure documentée et un point de transfert clair.
Un an plus tard, le premier workflow reste le même, car sa mise à jour semble risquée. Le second workflow a été ajusté quatre ou cinq fois par différentes personnes, car sa mise à jour semble sûre.
La vitesse de création des deux workflows était presque identique, mais la valeur générée par chacun sur 12 mois ne l'était pas.
Le choix entre « sans code » et « compatible avec le code » n'a jamais été définitif
Une correction manuelle devient une étape scriptée. Une étape scriptée devient un élément partagé et réutilisable que d'autres workflows peuvent appeler. Cette progression constitue le véritable cycle de vie, même si la plupart des contenus des prestataires traitent le choix entre « sans code » et « compatible avec le code » comme une décision unique prise au moment de l'achat.
Les acheteurs choisissent le low-code en partie pour éviter de se retrouver coincés avec une méthode de construction rigide, mais verrouiller ce choix peut se retourner contre eux dans les deux cas. Si vous allez trop loin dans le « sans code », le premier cas particulier que l'interface ne peut pas gérer sera résolu par une solution de contournement ajoutée en dehors de la plateforme. Si vous privilégiez trop le « code-first », l'équipe passera des mois à construire ce qu'un canevas géré aurait traité nativement, puis héritera de toute la maintenance que le low-code était censé leur épargner.
La meilleure question à poser est : un workflow peut-il combiner une étape de glisser-déposer avec une ligne de SQL ou de Python, sans avoir à tout reconstruire à chaque fois que les exigences changent ? Cette capacité est plus importante que le fait d'être étiqueté « sans code » ou « compatible avec le code », car les besoins d'un workflow restent rarement figés longtemps. Une jointure par glisser-déposer qui fonctionne parfaitement au lancement pourrait nécessiter une étape de regex personnalisée six mois plus tard, après qu'un système source a commencé à envoyer un champ mis en forme différemment de ce qu'il était auparavant.
Si la plateforme ne permet que le glisser-déposer, cette étape de regex est créée ailleurs, dans un script connu uniquement de son auteur. Le workflow « fonctionne » toujours, mais la logique qui compte réellement s'est échappée du système censé la gérer.
Existe-t-il un workflow au sein de votre équipe qui est bloqué actuellement, précisément parce que ce choix a été fait trop tôt et que personne ne l'a remis en question depuis ?
Restreindre le citizen development conduit inévitablement au shadow IT
Voici le problème auquel vous serez probablement confronté lorsque vous restreindrez le citizen development pour garder le contrôle : vous obtiendrez généralement plus de shadow IT, et non moins. Ce paradoxe survient parce que la demande d'automatisation ne disparaît pas simplement lorsque vous bloquez l'accès. Elle se déplace vers l'outil le plus facile à obtenir sans demander la permission, ce qui est rarement l'outil que quiconque aurait choisi délibérément.
Une étude de Forrester sur le citizen development révèle qu'au moins deux tiers des organisations disposent déjà d'une stratégie formelle de citizen development ou prévoient d'en élaborer une dans les 12 prochains mois. Forrester a identifié trois façons de procéder et de la déployer à grande échelle de manière responsable :
- En solitaire : une petite équipe autonome intégrée à une business unit
- Démocratie : un modèle largement ouvert et accessible à tous, avec des garde-fous définis sur ce qu'il est possible de créer
- Fédération : une approche hybride qui combine les deux, avec des normes centrales et une création distribuée
La meilleure façon de gérer le citizen development est de mettre en place la structure de gouvernance avant que la demande ne la dépasse, plutôt que d'essayer de rattraper le retard après coup.
Mais avant de pouvoir construire cette structure, vous devez convenir de qui se chargera réellement de la construction. Une étude du MIT sur le citizen development distingue trois rôles distincts :
- Les citizen developers créent des applications.
- Les citizen automators configurent des automatisations entre des systèmes qui ne communiquent pas nativement entre eux.
- Les citizen data scientists créent les modèles et les tableaux de bord.
Chacun de ces rôles nécessite un type de supervision différent, et les regrouper tous sous le terme « citizen development » ne fait que masquer cette distinction.
L'objectif n'est pas d'avoir moins de personnes créant des workflows. Il s'agit de les faire construire au sein d'un système qui permet de garder le travail visible et auditable. L'analytique en libre-service est un excellent exemple de cette même idée appliquée en pratique : lorsque l'IT a cessé de la considérer comme une menace pour commencer à concevoir son ergonomie, l'adoption a décollé.
Honnêtement, la question « Les analystes devraient-ils être autorisés à automatiser leur propre travail ? » a trouvé sa réponse il y a longtemps, dès la première fois que quelqu'un a écrit une macro juste pour s'épargner un après-midi de travail. Cette question n'est donc plus vraiment celle que l'IT devrait se poser.
La vraie discussion porte sur l'emplacement des garde-fous, sur les workflows qui nécessitent un propriétaire documenté et une étape de révision avant de toucher à un chiffre financier, et sur ceux qui présentent un risque suffisamment faible pour qu'un citizen automator puisse les déployer sans attendre la réponse à une demande d'assistance. Si vous évitez cette conversation, vous ne vous retrouverez pas avec moins de citizen development. Vous en aurez tout autant, mais vous ne pourrez plus le voir.
Liste de contrôle pour vos discussions avec un prestataire de solutions low-code
Les quatre questions suivantes sont pertinentes pour toutes vos discussions avec un prestataire, quelle que soit la plateforme que vous évaluez :
- La logique du workflow peut-elle évoluer entre « sans code » et « compatible avec le code » sans nécessiter une reconstruction ?
- Le citizen development au sein de la plateforme est-il géré et visible, ou simplement autorisé et non surveillé ?
- Les workflows sont-ils conçus comme des composants réutilisables et documentés, ou comme des scripts ponctuels que personne d'autre ne peut ouvrir en toute sécurité ?
- La plateforme prend-elle en charge une itération continue à mesure que les exigences évoluent, ou seulement le déploiement initial ?
Le low-code perd tout son sens lorsque rien n'est réutilisé
Ce qui limite un déploiement low-code revient presque toujours à la réutilisation : le workflow a-t-il été conçu pour être repris ou pour être oublié dès qu'il fonctionne ?
À titre d'exemple, voici comment cette question de réutilisation se pose généralement au sein d'une équipe d'approvisionnement qui rapproche les exceptions de bons de commande avec les factures des fournisseurs. Une personne de l'équipe finit généralement par créer une macro Excel personnelle qui signale les écarts dans les montants en dollars, et cela fonctionne souvent assez bien pour que personne ne s'interroge pendant des années, ce qui, en la matière, représente une éternité.
Ce type de macro détecte souvent la plupart des types d'exceptions proprement, mais manque les cas particuliers auxquels personne n'a pensé, comme les erreurs de mise en forme des numéros de commande entre le système ERP et le PDF de la facture, une particularité propre à la façon dont certains fournisseurs mettent leurs documents en forme. Des lacunes de ce genre sont exactement le type d'éléments qui déclenchent une alerte lors d'un audit SOX.
Si vous avez déjà hérité de la feuille de calcul d'un autre collaborateur, ce scénario vous semblera familier. L'analyste qui gère habituellement la feuille de calcul est absent, et la liste d'exceptions à traiter s'allonge pendant quelques semaines avant que quelqu'un ne s'en aperçoive, car personne d'autre dans l'équipe ne savait que la macro existait, et encore moins comment l'utiliser.
Cette défaillance est généralement ce qui pousse une équipe à reconstruire correctement la logique de correspondance, sous la forme d'un composant de workflow documenté et réutilisable, doté de sa propre planification et de son propre déclencheur, incluant tous les cas particuliers que la macro initiale avait omis.
Rien de tout cela ne consiste à construire plus rapidement. Il s'agit de construire quelque chose qui ne dépend pas du fait qu'une seule personne se souvienne de son existence, ce qui est tout aussi important pour un responsable financier ou un auditeur que pour l'équipe.
Voici un exemple de composant réutilisable, dans ce cas une macro, créée dans Alteryx :
| Avant : macro personnelle | Après : composant réutilisable | |
|---|---|---|
| Propriétaire | Un analyste, non documenté | Partagé, documenté, ouvert à l'équipe |
| Couverture des exceptions | 7 types sur 9 | Les 9, y compris le manque de correspondance du n° de bon de commande |
| Temps pour le rapprochement | Manuel sur plusieurs jours | Liste des exceptions traitées le jour même |
| Réutilisation dans toutes les catégories | Aucune ; reconstruit intégralement à chaque fois | Réutilisé dans deux autres catégories de dépenses, sans reconstruction |
Si cette situation correspond à celle de votre équipe, il est utile de mettre à l'épreuve l'état actuel de votre propre workflow avant de choisir un prestataire. Notre page sur le passage des feuilles de calcul aux workflows explique à quoi ressemble concrètement ce passage de feuilles de calcul gérées par une seule personne à des workflows documentés et réutilisables.
L'automatisation ne s'arrête pas au déploiement
Un workflow automatisé une fois et jamais réexaminé se dégrade de la même manière qu'une feuille de calcul non entretenue, mais de façon moins visible. Le problème se manifeste plus tard, généralement sous la forme d'un avertissement lors d'un audit ou d'un chiffre qui a cessé de correspondre à la réalité.
L'idée de composant réutilisable issue de l'exemple des achats s'avère à nouveau payante ici. Mettez à jour le composant de correspondance partagé une seule fois, par exemple si un prestataire change ou si un seuil est modifié, et chaque workflow basé sur celui-ci se mettra à jour automatiquement. Plus besoin de rechercher une dizaine de copies pour les corriger une par une, car il n'existe qu'une seule copie au départ.
Les assistants d'IA en langage naturel sont aussi concernés ici, et il est important de définir clairement ce qu'ils font réellement. Ask Alteryx en est un bon exemple. Il aide une équipe à interroger ou à mettre à jour un workflow géré existant en langage clair, mais ne se substitue pas à la structure de gouvernance sous-jacente. Considérez-le comme l'assistant, et non comme l'architecte : deux rôles différents, qu'il est utile de bien distinguer lorsque vous évaluez un outil.
La liste de contrôle, testée avec Alteryx One
Voici comment Alteryx se positionne par rapport à l'évaluation des prestataires dont nous avons parlé plus tôt.
| Question | Réponse avec Alteryx One |
|---|---|
| La logique peut-elle évoluer entre une approche sans code et une approche compatible avec le code sans nécessiter de reconstruction ? | Les workflows combinent des étapes par glisser-déposer avec du Python et du SQL natifs sur le même canevas, afin qu'une équipe ne soit pas cantonnée au choix effectué lors de l'acquisition. |
| Le citizen development est-il géré et visible, et pas seulement autorisé ? | L'accès basé sur les rôles et l'historique des versions offrent à l'IT la visibilité nécessaire pour permettre aux analystes de créer sans jamais perdre de vue ce qui a été fait. |
| Les workflows sont-ils des composants réutilisables ou des scripts ponctuels ? | Les macros et les applications analytiques sont créées une seule fois sous forme de composants documentés et partageables, suivant le même principe que celui qui a transformé le processus de rapprochement de l'équipe achats en une infrastructure partagée. |
| La plateforme prend-elle en charge une itération continue, et pas seulement le déploiement initial ? | Copilot aide les équipes à interroger et à mettre à jour les workflows existants en utilisant le langage naturel, en s'appuyant sur la structure encadrée déjà en place. |
Se lancer dans l'automatisation des workflows avec le low-code
Si vous pesez encore le pour et le contre, l'automatisation des workflows d'analystes récurrents et un cadre d'évaluation formel vont plus loin dans les détails de cet argument que ne peut le faire cet article.
Mais vous n'avez pas besoin de lire tout, ni d'adopter une plateforme complète, avant de vous lancer. Choisissez un rapport récurrent ou un processus de rapprochement manuel, qui existe probablement encore dans la feuille de calcul personnelle de quelqu'un, et reconstituez uniquement cet élément en tant que composant réutilisable et encadré. Voyez ce qu'il en est avant de décider si le reste du catalogue mérite d'être transféré.
L'enseignement à tirer, c'est que l'automatisation des workflows en low-code fait ses preuves sur la durée et la responsabilité, et pas seulement sur la rapidité du premier déploiement Alteryx One a été conçu exactement dans cette optique, et un essai gratuit est le moyen le plus rapide de savoir si la plateforme aux exigences de votre propre workflow.