Un projet complexe de gestion des clés de répartition des coûts pour une banque suédoise. Une équipe expérimentée sur Appian. Et pourtant, tout allait mal. Ce retour d'expérience raconte comment une simple story map a changé le cours du projet en moins de deux mois.

Le tableau à mon arrivée

Quand je suis intervenu sur ce projet, le diagnostic était clair à l'oeil nu : ça ne tournait pas rond. Les échanges entre l'équipe de développement et le client étaient tendus, parfois franchement conflictuels. Et ce n'était pas mieux en interne les développeurs eux-mêmes ne s'accordaient pas sur les priorités, sur ce qui devait être livré, ni dans quel ordre.

Le projet portait sur la gestion des clés de répartition des coûts entre les différents centres de coûts de la banque, selon des règles métier précises et complexes. Le genre de sujet qui demande une compréhension fine du domaine, une logique structurée, et une vraie coordination entre les équipes techniques et métier. Pas le genre de projet où on peut se permettre de naviguer à vue.

Pourtant c'est exactement ce qui se passait.

Le réflexe habituel : chercher le bug technique

Face à un projet Appian qui déraille, le réflexe naturel est de chercher le problème dans le code. L'architecture est-elle mal pensée ? Les intégrations sont-elles défaillantes ? La plateforme est-elle mal configurée ? Ce sont des questions légitimes, et j'aurais pu passer des semaines à fouiller dans cette direction.

Mais quelque chose ne collait pas dans ce raisonnement. L'équipe était expérimentée. Les développeurs connaissaient Appian. Le problème n'était pas là.

Sans vision globale, tout le reste s'effondre

L'absence de vision commune avait des conséquences très concrètes sur le projet. Sans clarté sur ce qu'il fallait construire, personne ne pouvait prioriser correctement. Sans priorisation, le planning ne reflétait pas la réalité des dépendances et des complexités. Et sans planning réaliste, l'équipe travaillait sur des sujets qui n'étaient pas les plus importants, laissant les vrais enjeux sans réponse.

Le client voyait des livraisons qui ne répondaient pas à ses attentes. L'équipe de dev recevait des retours négatifs sur un travail qu'elle pensait avoir bien fait. Les tensions montaient des deux côtés, chacun convaincu que l'autre ne comprenait pas le sujet. En réalité, personne ne parlait de la même chose parce que personne n'avait la même carte du terrain.

La décision : repartir de la story map

J'ai convaincu le Product Owner de marquer une pause. Pas pour tout remettre à plat, pas pour changer d'équipe ou de technologie juste pour prendre le temps de reconstruire une vision partagée du projet avant d'aller plus loin.

L'outil choisi était la story map. Le principe est simple : cartographier l'ensemble des fonctionnalités du produit sous forme de parcours utilisateur, puis les organiser par priorité de valeur métier. Ce n'est pas un exercice de planification au sens technique du terme c'est avant tout un exercice d'alignement.

Ce que la session a révélé était instructif. Certaines fonctionnalités considérées comme secondaires par l'équipe technique étaient en réalité bloquantes pour le client. D'autres, sur lesquelles beaucoup d'énergie avait été dépensée, n'étaient pas urgentes. Les règles de répartition des coûts les plus complexes n'avaient jamais été formalisées clairement chacun en avait une interprétation différente.

Reprioriser, puis planifier

Une fois la story map construite et validée avec le PO, nous avons repriorisé le backlog en nous appuyant dessus. Les cérémonies Agile ont repris leur rôle réel : les sprint planning sont devenus des moments de décision, les daily standups ont retrouvé leur utilité, et les retrospectives ont permis d'ajuster au fil du temps.

L'équipe savait enfin pourquoi elle travaillait sur ce qu'elle travaillait. Le client voyait des livraisons cohérentes avec ce qu'il attendait. Les tensions se sont dissipées rapidement non pas parce que les gens avaient changé, mais parce que le cadre de travail était enfin clair.

Moins de deux mois plus tard

En moins de deux mois à partir de la session story map, le projet était sur de bons rails. Les métriques de livraison s'étaient améliorées, le backlog était clair, et le PO exprimait un feedback positif qu'il n'avait pas eu depuis longtemps sur ce projet. Pas parce qu'on avait écrit du meilleur code. Parce qu'on avait construit une compréhension partagée de ce qu'il fallait faire.

Ce que j'en retiens

Ce projet m'a rappelé quelque chose que j'avais déjà observé sur d'autres missions : dans la majorité des projets en difficulté que j'ai croisés, la cause racine n'est pas technique. Elle est organisationnelle. L'équipe ne manque pas de compétences elle manque de clarté.

Quand un projet Appian déraille, la première question à se poser n'est pas "qu'est-ce qui ne marche pas dans le code ?". C'est "est-ce que tout le monde a la même définition du succès ?".

Souvent, la réponse est non. Et c'est là qu'il faut commencer.

Asset management, banque privée suisse, deadline réglementaire non négociable. Quatre mois pour livrer une plateforme de gestion des données auditables sur Appian fonds, mandats, cycles de vie complets, préparation de l'intégration DWH et client reporting. Ce retour raconte comment ça s'est passé.

Le contexte

Septembre 2019. Une banque suisse active dans l'asset management nous confie un projet ambitieux : construire une V1 fonctionnelle de gestion des données de référence la master data couvrant l'ensemble de ses fonds et mandats, avec livraison attendue pour fin décembre. Quatre mois, pas un de plus.

La date n'était pas négociable. Elle l'était encore moins que d'habitude, parce qu'elle répondait à une exigence de la FINMA : la banque devait disposer d'une gestion auditable de ses données avant la fin de l'exercice. Pas une recommandation, pas un objectif interne une obligation réglementaire avec les conséquences qui vont avec si elle n'est pas remplie.

Le périmètre fonctionnel était large. Il fallait couvrir la gestion complète du cycle de vie des fonds et des mandats : création, validation, modification, clôture, avec les règles métier associées à chaque statut. Il fallait aussi préparer les interfaces nécessaires à l'alimentation du Data Warehouse et au client reporting deux chantiers qui allaient démarrer juste après et qui dépendaient directement de ce que nous allions livrer.

Ce que "implémentation agressive" veut dire concrètement

Quand le périmètre est large et le calendrier serré, la tentation est de rogner sur la qualité ou sur le scope. Nous avons fait le choix inverse : tenir le périmètre en accélérant le rythme d'implémentation, sans sacrifier la robustesse de ce qui était livré.

Appian est une plateforme bien adaptée à ce type de contrainte. Sa capacité à produire des applications fonctionnelles rapidement n'est pas un argument marketing c'est une réalité que j'ai vérifiée sur plusieurs projets. À condition de savoir l'utiliser correctement, et de ne pas perdre de temps sur des sujets secondaires.

Sur ce projet, "correctement" voulait dire deux choses précises : une définition rigoureuse de ce qu'on livrait, et une organisation Agile qui ne laisse aucune ambiguïté s'installer.

DOD et DOR : pas des formalités

La Definition of Done et la Definition of Ready sont deux outils Agile que beaucoup d'équipes définissent en début de projet et n'appliquent jamais vraiment. Sur ce projet, elles ont été au centre de notre organisation dès le premier sprint.

La Definition of Ready fixait les conditions minimales pour qu'une user story entre en sprint : critères d'acceptance rédigés, règles métier documentées, dépendances identifiées, maquette ou prototype validé par le PO. Aucune story ne démarrait sans remplir ces critères. Ce n'est pas une règle bureaucratique c'est ce qui évite de découvrir en milieu de sprint qu'une règle métier est ambiguë ou qu'une dépendance n'a pas été anticipée.

La Definition of Done était tout aussi ferme : développement complet, tests unitaires passants, revue de code effectuée, validation fonctionnelle par le PO, documentation à jour. Une story partiellement livrée n'était pas une story livrée. Sur un projet à contrainte réglementaire forte, cette discipline n'était pas optionnelle.

Le résultat de cette rigueur : des sprints prévisibles, des vélocités stables, et un backlog qui reflétait l'état réel du projet plutôt que l'état espéré.

La complexité de la master data en asset management

La gestion des données de référence en asset management est un domaine techniquement exigeant. Un fonds n'est pas un objet statique il a un cycle de vie : création en attente de validation, validation réglementaire, ouverture aux souscriptions, fermeture partielle, liquidation. Chaque statut a ses règles, ses acteurs, ses délais, ses impacts sur les données aval.

Les mandats ajoutent une couche de complexité supplémentaire : ils sont liés à des clients, à des stratégies d'investissement, à des contraintes contractuelles spécifiques. La gestion de leurs données demande une modélisation fine des relations entre entités, et une traçabilité complète de chaque modification pour satisfaire les exigences d'audit.

C'est précisément pour cette traçabilité qu'Appian était le bon choix. Le moteur de processus natif de la plateforme gère naturellement les flux de validation, les historiques d'états, et les logs d'actions sans développement spécifique sur ces aspects. Ce sont des capacités que d'autres plateformes nécessiteraient de construire from scratch.

Préparer l'aval sans le livrer

Un aspect du projet moins visible mais aussi important que les fonctionnalités visibles : la préparation des interfaces pour le Data Warehouse et le client reporting. Ces deux chantiers devaient démarrer en janvier 2020, et ils dépendaient de la qualité et de la structure des données que nous allions produire.

Nous avons donc travaillé dès le départ avec les équipes en charge de ces projets aval pour définir les modèles de données, les règles de transformation et les formats d'export attendus. Ce travail de préparation n'est pas spectaculaire. Il est rarement valorisé dans les bilans de projet. Mais c'est ce qui évite que la V2 commence par six semaines de reprise de la V1.

Fin décembre 2019

La V1 a été livrée dans les délais. Toutes les fonctionnalités du périmètre initial étaient opérationnelles. La gestion des données était auditable, documentée, et prête pour un contrôle FINMA. Les interfaces pour le DWH et le client reporting étaient spécifiées et partiellement implémentées.

Le feedback du client était positif pas le genre de "c'est bien" poli qu'on reçoit parfois à la fin d'un projet difficile, mais une satisfaction réelle sur la qualité des livrables et le respect du calendrier dans un contexte qu'ils savaient contraignant.

Ce projet reste pour moi l'un des exemples les plus clairs de ce qu'Appian peut faire quand on l'utilise bien, avec une organisation qui correspond au rythme que la plateforme permet. Quatre mois, un périmètre large, une contrainte réglementaire dure. Et une livraison propre.

La gestion des demandes internes, achats, congés, matériel IT est un processus banal dans toute organisation. Mais sa mise en œuvre est rarement simple : formulaires éparpillés, validations par email, aucune traçabilité. Appian permet de construire une solution complète, paramétrable et prête à l'emploi en quelques jours.

Le problème que tout le monde connaît

Dans la plupart des organisations, soumettre une demande interne relève du parcours du combattant. Un email au manager, une pièce jointe Excel, une relance une semaine plus tard, et une approbation qui arrive ou pas sans horodatage ni traçabilité. Quand les auditeurs demandent qui a validé quoi et quand, la réponse est souvent dans une boîte mail introuvable.

C'est ce constat qui a conduit à développer cette application sur Appian : une plateforme de gestion des demandes internes entièrement paramétrable, où chaque type de demande, chaque formulaire et chaque workflow de validation est configurable par l'administrateur sans intervention technique.

Un tableau de bord qui donne la visibilité en temps réel

La page d'accueil administrative concentre l'essentiel de ce dont un responsable a besoin : nombre de demandes actives, demandes en attente de réponse, taux d'approbation du mois, et délai moyen de validation comparé à l'objectif fixé. Les types de demandes configurés sont visibles en un coup d'œil, avec leur statut d'activation.

Un détail qui compte : la colonne "Truc & astuce" en haut à droite. Ce n'est pas de la décoration c'est un exemple de ce qu'Appian permet facilement : des conseils contextuels dynamiques qui guident les utilisateurs sans formation préalable. "Pensez à joindre un devis pour tout achat supérieur à 500 CHF cela accélère l'approbation de 40% en moyenne." Ce genre de message réduit les allers-retours et améliore la qualité des demandes soumises.

Créer un type de demande en trois étapes

La vraie force de l'application est dans sa capacité de paramétrage. Un administrateur peut créer un nouveau type de demande Fourniture, Matériel IT, Congé exceptionnel, Mobilier Bureau sans toucher au code. Le processus se déroule en trois écrans successifs.

Étape 1 Caractéristiques. On nomme le type de demande, on lui associe une description, une icône parmi une bibliothèque prédéfinie, et on l'active ou non. La date de création est automatiquement horodatée.

Étape 2 Formulaire. L'administrateur choisit quels champs sont affichés dans le formulaire de demande, lesquels sont obligatoires, lesquels sont optionnels. Les champs système date de soumission, demandeur, numéro de demande, priorité sont toujours présents. Les champs configurables montant CHF, justification, fournisseur, pièce justificative, quantité sont activables par simple toggle. Un aperçu en temps réel s'affiche à droite.

Étape 3 Workflow. C'est là que se définit le circuit de validation : nombre de niveaux d'approbation (1 ou 2), seuil de montant au-delà duquel le niveau 2 est automatiquement déclenché, approbateurs principal et secondaire pour chaque niveau, délais de rappel et règles d'escalade en heures.

L'expérience côté demandeur

Du côté de l'utilisateur final, la création d'une demande est pensée pour être aussi simple que possible. Le formulaire s'adapte automatiquement au type de demande sélectionné seuls les champs pertinents apparaissent. La sélection du type se fait par tuiles visuelles avec icônes, ce qui rend la navigation intuitive même pour des utilisateurs peu à l'aise avec les outils numériques.

La validation côté approbateur

Quand une demande arrive dans la file de validation, l'approbateur accède à une vue claire : les détails de la demande à gauche numéro, demandeur, type, objet, date de soumission, justification et le panneau de décision à droite avec un champ commentaire et les boutons Approuver / Réfuser. Chaque décision est horodatée et archivée. La traçabilité est native, sans configuration supplémentaire.

Adapter en quelques heures à un client spécifique

C'est là que la flexibilité d'Appian prend tout son sens dans un contexte SaaS. Cette application a été conçue pour être multi-client dès le départ. Chaque client dispose de ses propres types de demandes, ses propres formulaires, ses propres circuits de validation et ses propres seuils. Passer d'une configuration générique à une configuration spécifique à une organisation avec ses process, ses rôles, ses règles métier demande quelques heures, pas plusieurs semaines.

Pour une PME qui veut digitaliser ses demandes d'achat, un hôpital qui gère ses demandes de matériel, ou une institution publique qui doit tracer ses demandes de congés exceptionnels : le socle est le même, la configuration est différente, le délai de mise en production est court.

C'est exactement la proposition de valeur du low-code bien utilisé non pas faire des choses qui seraient impossibles autrement, mais faire en quelques jours ce qui prendrait normalement plusieurs mois.

Vous avez entendu parler d'Appian. Peut-être lors d'un appel d'offres, d'une recommandation, ou d'une veille technologique. Vous êtes curieux, mais vous n'avez pas encore vu ce que la plateforme peut faire concrètement dans votre contexte. Ndziya vous propose de le découvrir gratuitement, en 72 heures, sur un cas que vous choisissez.

Le problème avec les démonstrations génériques

La plupart des démonstrations de plateforme se ressemblent. Un commercial présente un cas d'usage standard, bien rodé, qui met la technologie en valeur dans les meilleures conditions possibles. C'est visuellement convaincant. Mais au moment de transposer à votre contexte vos processus, vos contraintes, vos utilisateurs l'écart entre la démo et la réalité laisse des doutes.

Ces doutes sont légitimes. Et ils retardent souvent des décisions qui auraient été bonnes.

L'approche POC répond à ce problème directement : au lieu de vous montrer ce qu'Appian peut faire en général, on vous montre ce qu'Appian peut faire pour vous.

Ce que Ndziya propose

Concrètement, voici comment ça se passe :

• Jour 1 Cadrage (1h) : un échange pour comprendre votre contexte, identifier le cas d'usage le plus démonstratif, et définir le périmètre du POC. C'est vous qui choisissez le sujet un processus que vous voulez automatiser, un formulaire que vous voulez digitaliser, un workflow que vous voulez fluidifier.
• Jours 1-3 Construction : nous développons le prototype sur Appian. Interface utilisateur, logique de processus, règles métier de base tout ce qui permet de rendre le cas d'usage tangible et testable.
• Jour 3 Livraison et démo live : présentation du prototype avec vos équipes, démonstration en direct, questions-réponses. Vous repartez avec une vision claire de ce qu'un projet complet représenterait.

Pourquoi offrir ce POC gratuitement ?

La question mérite d'être posée directement.

Parce que la meilleure façon de démontrer la vélocité d'Appian, c'est de la montrer en action pas d'en parler. Un prototype livré en 72 heures est un argument que ni un document ni une présentation ne peuvent remplacer. Et parce que, dans les organisations qui ont vu ce qu'Appian peut faire sur leur propre contexte, les décisions de déploiement deviennent infiniment plus simples à prendre.

Le POC est notre façon de démarrer une relation de confiance. Pas de pression commerciale, pas d'engagement requis de votre côté. Juste un prototype fonctionnel, livré, sur votre cas d'usage.

Quels cas d'usage pour un POC en 72h ?

Appian couvre un spectre très large. Voici quelques exemples de cas d'usage régulièrement traités en quelques jours :

• Gestion des demandes internes avec workflow de validation multi-niveaux
• Processus d'onboarding client ou collaborateur avec collecte documentaire
• Suivi d'approbation de contrats ou de devis
• Gestion d'incidents ou de tickets internes
• Automatisation d'un processus KYC ou compliance simplifié
• Tableau de bord de suivi d'un portefeuille de projets
• Formulaire de demande réglementaire avec circuit de signature
• Tout autre processus métier que vous souhaitez digitaliser

Si vous n'êtes pas sûr que votre cas d'usage est réalisable en 72 heures, posez la question lors du premier échange. Nous serons honnêtes sur ce qui est faisable dans ce délai et sur ce qui demanderait plus de temps.

À qui s'adresse cette offre ?

À toute organisation qui étudie sérieusement l'adoption d'Appian DSI, directeur de programme, responsable transformation digitale, ou direction générale. Le POC est particulièrement utile dans trois situations :

• Vous êtes en phase d'évaluation et souhaitez comparer Appian à d'autres plateformes sur un cas concret
• Vous avez déjà la conviction mais avez besoin d'un prototype pour convaincre en interne
• Vous voulez évaluer la vélocité de la plateforme avant de vous engager sur un projet plus long

Ce que le POC ne remplace pas

Un POC livré en 72 heures est un prototype, pas une application de production. Il démontre les capacités de la plateforme sur votre cas d'usage il ne remplace pas les étapes de cadrage, de design et de développement d'un projet réel. Ce que vous verrez à l'issue du POC, c'est ce qu'Appian peut faire, pas ce qu'il a déjà fait. La différence est importante et nous la posons clairement dès le départ.