Comment peupler et maintenir à jour une liste déroulante dans une Alteryx Analytic App
1. Le vrai problème : pourquoi les listes déroulantes cassent en production
Une histoire vécue. Un contrôleur de gestion me contacte : son Analytic App déployée sur Alteryx Server ne fonctionne plus. Diagnostic en trois minutes : la liste déroulante « Sélectionner l'entité » propose 12 options — mais l'entreprise en a acquis 3 nouvelles depuis la dernière mise à jour du workflow. Résultat : rapport incomplet, panique côté métier, appel en catastrophe.
Ce cas n'est pas isolé. C'est probablement l'une des trois erreurs les plus fréquentes que j'observe chez les utilisateurs Alteryx qui construisent des Analytic Apps en production.
Pourquoi ça casse : parce que la liste a été définie en dur, dans la configuration de l'outil List Box, au moment du développement. Le workflow n'a aucun moyen d'apprendre qu'une nouvelle entité existe. Il continue à afficher fidèlement les 12 valeurs de mars 2024 — même en 2026.
Le "so what" pour votre organisation
Si vous avez déjà des Analytic Apps en production avec des listes déroulantes statiques, faites l'audit dès la semaine prochaine : combien risquent de casser au prochain ajout de donnée ? Sur mes 5 dernières missions, la réponse a été systématiquement : au moins deux.
2. Deux approches — statique ou dynamique
Il existe exactement deux façons de peupler une liste déroulante dans une Alteryx Analytic App. Comprendre la différence entre les deux, c'est déjà éviter 80 % des pièges.
2.1 Liste déroulante statique (valeurs saisies manuellement)
Dans ce premier scénario, la liste de valeurs est codée en dur dans le workflow et ne dépend d'aucune source de données externe ou dynamique.
Quand l'utiliser ?
- - La liste de valeurs est courte (moins de 10-15 items)
- - Les valeurs ne sont pas censées évoluer
- - La simplicité prime sur la flexibilité (exemple : liste de 4 régions commerciales figées, choix Oui / Non / Peut-être)
Comment ça fonctionne ?
On définit manuellement les items de la liste directement dans la configuration de l'outil List Box.
Limites de cette approche
Si la liste doit être mise à jour plus tard, il faut :
- -Ouvrir le workflow dans Alteryx Designer
- -Ajouter ou éditer manuellement les valeurs
- -Re-publier l'application sur Alteryx Server
-
Cette approche n'est pas adaptée dès que les valeurs évoluent dans le temps. Elle génère une dette de maintenance qui, en pratique, finit toujours par exploser au pire moment.
2.2 Liste déroulante dynamique (recommandée)
Dans ce second scénario, la liste dérive directement de la donnée — donc elle se met à jour automatiquement dès qu'une nouvelle valeur apparaît à la source.
C'est l'approche recommandée pour toute Analytic App destinée à durer plus de quelques semaines en production.
Le "so what"
Un principe simple à graver au-dessus de votre bureau : si la liste de valeurs peut évoluer, ne la codez jamais en dur. Le surcoût de la version dynamique est de 30 à 45 minutes de dev. Elle se rembourse dès la première évolution de vos données.
3. La méthode : deux applications chaînées
L'idée générale : construire un petit workflow de préparation qui produit une colonne contenant les valeurs autorisées, puis utiliser cette colonne pour peupler la liste déroulante.
La logique de préparation peut vivre à deux endroits :
- - Dans un workflow séparé (recommandé si la préparation est complexe ou partagée entre plusieurs Apps)
- - Dans la première partie de la même Analytic App
-
Pour cet exemple, je choisis l'architecture la plus robuste : deux Analytic Apps chaînées.
- Application 1 : extrait les noms de feuilles d'un fichier Excel et sauvegarde en YXDB
-
- Application 2 : lit le YXDB créé par l'App 1 et l'utilise pour peupler la liste déroulante, puis filtrer les données
Cette architecture sépare la préparation (App 1) de son usage (App 2). C'est un pattern robuste, modulaire, testable — et bien plus facile à faire évoluer que 300 lignes dans un unique workflow.
4. Application 1 — Extraire les noms de feuilles Excel
Pour illustrer, j'utilise un fichier travel.xlsx qui contient trois feuilles : Destinations, Budget, Schedule.
Étape 1 — Permettre à l'utilisateur de choisir un fichier Excel au runtime
- - Ajouter un outil File Browse pour permettre à l'utilisateur de sélectionner un fichier Excel à l'exécution
- - Connecter le File Browse à un outil Action, lui-même connecté à un outil Input Data
- Dans la configuration de l'Input Data, sélectionner l'option « List of Sheet Names »
-
Cette configuration retourne la liste des noms de feuilles du fichier Excel sélectionné, sous forme d'une colonne unique.
Étape 2 — Générer une colonne Value
- - Ajouter un outil Record ID au workflow
- - Cet outil crée une nouvelle colonne qui assigne un identifiant unique à chaque ligne
- - Renommer cette colonne en Value
-
Ce champ Value sera utilisé plus tard, en interne, par l'outil List Box pour tracer les sélections utilisateur.
Étape 3 — Préparer la structure de sortie
Ajouter un outil Select pour :
- - Renommer la colonne « Sheet Names » en Name
- - Changer le type de données de la colonne Value en String
-
Cette étape est essentielle : l'outil List Box attend que la source externe contienne exactement deux champs — Name et Value — tous deux compatibles avec des sélections de type chaîne.
Étape 4 — Écrire en YXDB
Le résultat est écrit dans un fichier YXDB (par exemple Out1.yxdb). Ce fichier sert de référence source dynamique pour la liste déroulante de la seconde application.
Concrètement, cela signifie :
- - Tout utilisateur qui lance l'App peut naviguer vers n'importe quel fichier Excel
- - La liste déroulante des noms de feuilles se met automatiquement à jour dès qu'un nouveau fichier est sélectionné
Le "so what"
Bien nommer vos fichiers intermédiaires n'est pas cosmétique. entities_reference.yxdb vous fera gagner des heures de debug 6 mois plus tard. Out1.yxdb, non.
5. Application 2 — Peupler la liste déroulante
La seconde application lit le fichier Out1.yxdb créé par l'App 1 et l'utilise pour peupler une liste déroulante.
Étape 5 — Lire le fichier YXDB
Ajouter un outil Input Data pour lire Out1.yxdb. Le fichier doit contenir deux champs requis :
- - Name : le label affiché à l'utilisateur
- - Value : la valeur interne utilisée par l'App
Étape 6 — Configurer l'outil List Box
Ajouter un outil List Box au workflow. Dans sa configuration :
- - Sélectionner Generate Custom List
- - Définir : Start Text → ", Separator → ",", End Text → "
-
Ce formatage garantit que les valeurs sélectionnées seront retournées sous forme de chaîne correctement délimitée et prête à être utilisée dans une clause SQL ou une expression de filtre.
Étape 7 — Définir la source externe (l'étape critique)
Dans l'onglet List Values :
- - Sélectionner External Source – Must contain Name & Value fields (can be relative path)
-
Dans le sous-onglet Properties :
- - Référencer le fichier Out1.yxdb en chemin relatif (impératif si l'App tourne sur Alteryx Server)
-
À partir de ce moment, la liste déroulante lit dynamiquement ses valeurs depuis le YXDB généré par l'Application 1.
Étape 8 — Configurer l'outil Filter
Ajouter un outil Filter au workflow. Il est configuré pour ne garder que les lignes où le champ Value correspond aux sélections de l'utilisateur.
L'expression du filtre utilise une condition placeholder, du type :
Value IN (...)
À ce stade, l'expression est statique. Elle sera mise à jour dynamiquement au runtime par l'outil Action.
Étape 9 — Configurer l'outil Action
- - Connecter un outil Action à l'outil List Box
- - Le connecter également à l'outil Filter
- - Type : Update Value (Default)
-
Au runtime :
- - L'outil Action remplace l'expression placeholder dans le Filter
- - La valeur de remplacement provient de la sélection de l'utilisateur dans le List Box
-
C'est ce qui rend l'App véritablement interactive : le workflow ne filtre plus que sur les feuilles effectivement choisies par l'utilisateur.
Le "so what"
Prenez le temps de bien comprendre le rôle de l'outil Action — c'est LE composant qui rend une Analytic App vraiment interactive. Sans lui, vous n'avez qu'un workflow avec des menus jolis mais inertes.
6. Pourquoi filtrer sur Value plutôt que sur Name
Quand on configure une liste déroulante dynamique dans une Alteryx Analytic App, la source externe doit fournir deux champs : Name et Value. Les deux sont requis, mais leurs rôles sont fondamentalement différents. Comprendre cette distinction, c'est comprendre pourquoi on filtre toujours sur Value.
Name — champ d'affichage uniquement
- - Représente le label affiché à l'utilisateur dans la liste déroulante
- - Pensé pour la lisibilité et l'usabilité
- - Peut contenir : espaces, caractères spéciaux, descriptions longues, accents
- - Pas adapté aux opérations techniques comme un filtre ou une substitution de paramètre
-
Value — champ technique et opérationnel
- - Représente la valeur réellement passée au workflow quand l'utilisateur fait une sélection
- - C'est le champ utilisé par l'outil Action pour remplacer les expressions au runtime
- - Doit être stable, unique, facile à manipuler programmatiquement
-
Filtrer sur Value garantit trois choses :
- - Comportement cohérent, même si les labels changent (renommer une entité en front n'impacte pas votre workflow)
- - Expressions plus propres, notamment quand plusieurs valeurs sont sélectionnées
- - Moins de problèmes avec les guillemets, les espaces et les caractères spéciaux
-
Le "so what"
Prenez 10 minutes de plus à la conception pour bien séparer Name et Value. Cela vous évitera des heures de debugging quand un utilisateur ajoutera un caractère accentué dans un nom d'entité — ce qui, en environnement français, arrive systématiquement.
7. Trois bonnes pratiques à appliquer sans exception
1. Toujours utiliser des chemins relatifs
Sinon votre application ne fonctionnera pas sur Alteryx Server. Le chemin absolu C:\Users\mouna\Documents\... de votre poste de dev n'existe pas sur le serveur. Résultat : App qui plante en production.
2. Nommer explicitement vos fichiers intermédiaires
entities_reference.yxdb plutôt que Out1.yxdb. Vous vous remercierez dans six mois.
3. Documenter la logique de rafraîchissement
Où et quand le YXDB est-il régénéré ? Manuellement par l'utilisateur ? Automatiquement chaque nuit via un Scheduled Workflow sur Server ? Cette information doit vivre quelque part — dans un commentaire de workflow, une doc technique, un README. Sans elle, la prochaine personne qui reprend le sujet sera perdue.
8. Key Takeaways
Si vos valeurs de liste déroulante dépendent d'une donnée qui peut évoluer :
- - Évitez les listes statiques — elles génèrent une dette de maintenance qui explose toujours au pire moment
- - Utilisez une approche dynamique, pilotée par la donnée
- - Envisagez des applications chaînées quand la liste dépend d'un choix utilisateur (sélection de fichier, notamment)
- - Filtrez toujours sur Value, jamais sur Name
- - Chemins relatifs, noms explicites, logique de rafraîchissement documentée — non négociable pour une App qui doit vivre en production
-
Cette méthodologie réduit considérablement la maintenance. Comptez 30 à 45 minutes de plus pour la version dynamique — investissement qui se rembourse dès la première évolution de vos données.
Si vous souhaitez former vos équipes aux bonnes pratiques de conception d'Analytic Apps Alteryx, notre programme Prime Elevate couvre en profondeur ces sujets — parlons-en ensemble.
Nous vous recontacterons dans les plus brefs délais.
Veuillez réessayer ou nous contacter à l'adresse contact@primeanalytics.fr.