Dans le cadre d’une masterclass animée par Nicolas Fabre (voir son profil LinkedIn), trois représentants de grands groupes – PwC, Giphar et le Bivwak (BNP Paribas) – ont partagé leur retour d’expérience sur l’intégration du NoCode dans leurs organisations. Leurs témoignages, concrets et complémentaires, offrent un éclairage utile à toute DSI ou direction d’ETI souhaitant structurer une Digital Factory. Un grand merci à Nicolas pour cette initiative précieuse.
Préambule pour cet article : Qu’est-ce que le no-code / Low-code
Pourquoi ont-ils mis en place des Digital Factories ou cellules NoCode ?
Deux points assumés :
1/ Face à des métiers en attente de solutions digitales, et à des DSI souvent sous tension, ces structures ont émergé comme une réponse pragmatique pour accélérer la livraison de solutions digitales.
- Chez PwC, le NoCode permet de réduire le time-to-market, en particulier sur les projets expérimentaux ou internes, dans une logique de « fail fast » assumée.
- Giphar, coopérative pharmaceutique fonctionnant avec un SI centralisé sous SAP, utilise sa cellule NoCode pour répondre aux besoins concrets et immédiats non couverts par les projets SAP.
- Quant à Bivwak, le hub d’accélération de BNP Paribas, il vise à faciliter l’émergence rapide de solutions innovantes dans les entités métiers du groupe, avec des moyens légers mais structurés.
2/ Le rôle de ces Digital Factories est aussi d’alléger la charge des DSI. Dans tous les cas, les intervenants constatent un écart croissant entre les besoins métiers du quotidien – souvent à faible ROI individuel mais à impact opérationnel réel – et la capacité des SI à les prendre en charge rapidement. Le NoCode agit alors comme une soupape d’agilité, capable de livrer des applications concrètes en quelques semaines plutôt qu’en plusieurs mois.
Une gouvernance hybride pour répondre aux exigences IT et aux réalités métiers
Ce que ces retours soulignent, c’est qu’il ne suffit pas de mettre un outil NoCode entre les mains d’un collaborateur pour réussir comme le propose l’approche « Citizen dévelopers ».
Cela repose sur un équilibre subtil entre rigueur IT et pragmatisme métier. La Digital Factory devient une zone tampon, qui facilite le dialogue entre des équipes métiers agiles mais peu formées aux enjeux de sécurité, et une DSI garante de la stabilité, de la conformité et de la maintenabilité.
Dans ce modèle, les MVP et développement sont cadrés dès le départ, les parcours utilisateurs construits en collaboration, et la maintenance anticipée. Ce dialogue permanent est la clé pour embarquer l’ensemble des acteurs – développeurs, UX, métiers, gouvernance – dans un projet commun.
Comment ces initiatives ont-elles été structurées ?
Les modèles varient selon les contextes, mais partagent une même logique de focalisation.
- PwC a constitué une véritable Digital Factory interne, pilotée comme un éditeur, avec une équipe mixte de développeurs traditionnels et d’experts NoCode.
- Giphar fonctionne avec une petite cellule NoCode au sein de la DSI, animée par un responsable issu du métier.
- Bivwak, lui, agit en support transverse : il n’a pas vocation à développer, mais à former, coacher, et structurer les projets dans les entités du groupe.
Le Citizen Developer y trouve sa place, mais toujours dans un cadre défini.
- PwC impose un design system, des règles de sécurité, et une gouvernance stricte.
- Bivwak forme ses UX et équipes communication à WeWeb pour leur permettre une autonomie sur certains contenus, tout en maîtrisant les déploiements. Dans ces organisations, le Citizen Dev n’est ni naïf, ni libre de tout faire : il est encadré, accompagné, et intégré dans un processus plus large.
Le choix des outils : une décision stratégique
Tous les participants ont souligné l’importance du choix technologique, et la nécessité d’un socle stable et cohérent. Les stacks les plus citées : WeWeb pour le front (souvent apprécié par les UX designers), Xano ou Supabase pour le back-end, FlutterFlow pour les applications mobiles. Ce trio répond à un besoin de modularité, de rapidité, et d’intégration avec les systèmes existants.
L’open source a été écarté par Pwc estimant qu’ils embarquent souvent des centaines de dépendances tierces, chacune avec leur propre licence (MIT, GPL, Apache, etc.). Cela rend difficile :
- l’analyse complète des obligations légales ;
- la garantie qu’aucune “licence contaminante” (ex : GPL) ne s’applique, ce qui pourrait contraindre PwC à ouvrir son propre code s’il le redistribue.
Un point souvent sous-estimé ressort clairement : le vendor lock-in. Dans un grand groupe, il ne s’agit pas seulement de préférer une interface ou une logique de développement, mais d’évaluer la capacité à exporter les données, à documenter, à migrer si nécessaire. PwC, notamment, n’adopte que des outils self-hostables pour les projets en production – un critère qui avait écarté Xano dans un premier temps. (Xano propose à présent le self hosting)
Équipe interne ou prestataire externe : quelle stratégie adopter ?
Sur ce sujet, les approches divergent.
- Giphar a fait le choix d’un mix équilibré : une petite équipe interne montée en compétence rapidement, épaulée ponctuellement par un prestataire spécialisé sur FlutterFlow.
- PwC a vécu une expérience décevante avec un partenaire externe et a choisi d’internaliser tous ses développements, pour des raisons de maîtrise qualité et de gouvernance.
- Bivwak expérimente actuellement un appel d’offre structuré, avec stack imposée, coach interne, et suivi de livraison. Cette approche permet de tester le modèle d’externalisation sans renoncer au contrôle.
La réussite d’un modèle externalisé repose, selon eux, sur trois éléments : un cadre de bonnes pratiques partagé dès le départ, un accompagnement actif du partenaire, et une logique de co-construction. L’objectif n’est pas seulement de livrer rapidement, mais de maintenir un produit viable dans le temps, sans générer de dette technique.
Zoom sur la sécurité : comment ont-ils géré le sujet dans des contextes sensibles ?
Sur ce point, les exigences sont élevées – à juste titre. Dans des environnements critiques comme ceux de PwC ou BNP Paribas, la sécurité est intégrée dès la phase de choix. Bivwak a ainsi fait auditer ses projets NoCode par la Red Team du groupe, avec un retour impressionnant : les failles détectées ont été corrigées en quelques heures. Xano et WeWeb, bien que jeunes éditeurs, ont accepté des engagements contractuels sur les délais de correction (SLA) et ont prouvé leur sérieux sur la durée.
Ce que cela dit pour Appy Makers et votre Digital Factory externalisée
Les enseignements de ces retours d’expérience confortent notre approche chez Appy Makers. Une Digital Factory efficace ne repose pas uniquement sur la technologie, mais sur la combinaison de trois piliers :
- une approche modulaire centrée sur l’usage et le ROI ;
- des outils éprouvés, performants et adaptables (Xano, WeWeb, FlutterFlow, Make) ;
- un accompagnement structurant mêlant diagnostics, co-construction, et gouvernance.
C’est ce que nous proposons à travers notre Digital Factory externalisée.
