L’organisation d’un projet No-Code / Low-Code : repenser les méthodes pour gagner en agilité
L’émergence des plateformes No-Code et Low-Code a fortement accéléré la vitesse de développement des applications. Malgré l’évolution des outils, de nombreuses entreprises persistent à encadrer ces projets avec des méthodes de gestion traditionnelles. Cette approche freine souvent la rapidité et la flexibilité qui sont pourtant les atouts majeurs de ces nouvelles technologies. Pour tirer pleinement parti du No-Code/Low-Code, il faut accepter de changer de paradigme : passer d’une logique de spécification abstraite à une logique de co-construction en temps réel.
Yannick Le Briquer, Directeur Général d’Anakeen, nous partage son expérience terrain et sa vision de l’organisation idéale pour mener à bien un projet No-Code / Low-Code.
Quelles sont les limites ou les lourdeurs des méthodes traditionnelles face à la rapidité des outils No Code/Low Code, et que préconises-tu ?
Les méthodes traditionnelles, comme le cycle en V, reposent sur un processus séquentiel lourd : spécifier, analyser, concevoir, développer, tester puis livrer. Dans ce modèle, le client est contraint de valider des descriptions abstraites sur le papier.
« Les descriptions fonctionnelles abstraites exigent du client un effort de lecture important sans lui offrir de visualisation concrète du résultat. Cette approche est chronophage et source de déception à la livraison, car le produit final s’aligne rarement sur ce que le client avait imaginé à partir des spécifications. »
Yannick Le Briquer, Directeur Général d’Anakeen
Face à la réactivité du No-Code / Low-Code, même les méthodes Agiles classiques peuvent s’avérer lourdes, avec leurs rédactions complexes de User Stories, leurs estimations par les équipes de développement et leurs engagements de livraison à trois semaines. Dans ce contexte, l’approche de co-construction directe et de prototypage rapide est bien plus adaptée.
« Avec le No-Code et le Low-Code, il est possible d’avoir l’utilisateur sur la chaise à côté et de construire la solution en même temps qu’il exprime son besoin. »
Cette approche permet de réaliser rapidement les fonctions demandées tout en matérialisant immédiatement les limites du possible pour le métier. Les attentes irréalistes sont tout de suite recadrées. L’application est déployée et adaptée en continu, et de manière itérative, sans enfermement dans un tunnel de développement aveugle.
A-t-on encore besoin de faire de nombreuses spécifications pour s’assurer de l’alignement avec le besoin ?
La réponse est non. Dans l’approche No-Code / Low-Code co-construite, la documentation détaillée produite a priori (avant le développement) perd son sens.
« C’est l’application même qui devient la spécification fonctionnelle. »
Au fil des ateliers, le besoin est traduit directement dans le prototype. Le client l’ajuste en direct (« il faudrait rajouter telle date ici »), et l’équipe boucle. Le résultat final valide l’alignement avec le besoin de façon beaucoup plus pragmatique qu’un document de 700 pages qui, de toute façon, risque d’être obsolète au moment de la livraison.
Cependant, une bonne documentation reste nécessaire pour la pérennité et la maintenabilité de l’application (pour les futurs administrateurs ou si le développeur initial change de projet). Mais cette documentation est désormais produite a posteriori. L’Intelligence Artificielle bouleverse d’ailleurs cette étape.
« Nous avons fait l’exercice récemment avec l’IA Claude Code : nous lui donnons l’application et nous lui demandons de rédiger la spécification, un cahier de test ou un plan de validation. Il le fait très bien et détecte même parfois des anomalies de conception ! »
Peux-tu me décrire à quoi ressemble une semaine type dans l’organisation d’un projet No Code / Low Code ?
Le rythme de croisière repose sur des cycles courts et très peu chronophages pour le client. La semaine type s’articule autour d’un atelier fonctionnel hebdomadaire avec le client.
- Restitution immédiate : L’atelier commence par la restitution de l’atelier précédent. Mais il n’y a pas de support PowerPoint : la restitution, c’est l’application elle-même, mise à jour.
- Configuration en direct : Nous menons les échanges et nous paramétrons en direct les nouvelles fonctions ou leurs extensions.
- Travail asynchrone : Si certaines fonctions sont jugées trop complexes ou trop longues à configurer en direct (pour ne pas perdre le temps du client), le développeur s’en charge dans la semaine, ce qui représente généralement une petite demi-journée de travail supplémentaire.
« Un projet mené récemment sur un trimestre a représenté une quinzaine d’ateliers, soit à peine une trentaine d’heures de disponibilité pour le client, pour plus d’une centaine d’heures de travail de notre côté. Le budget est totalement maîtrisé et le temps est consommé de manière efficace. »
L’idée de s’éloigner des standards de gestion de projet peut effrayer certaines DSI ou équipes, comment fais-tu pour les rassurer ?
Il est vrai que l’approche par ateliers successifs est moins formalisée contractuellement qu’un cycle en V classique, qui juge la conformité par rapport à un cahier des charges rigide. Le changement d’habitudes peut créer des frictions, notamment dans des organisations très structurées.
« Conserver un cycle de projet classique tout en utilisant une plateforme No-Code / Low-Code rend l’effort d’organisation et de documentation totalement démesuré par rapport à la complexité réelle du projet. La méthode n’est plus adaptée aux outils. »
Pour rassurer les DSI et les directions de projet, plusieurs arguments sont clés :
- Une maîtrise budgétaire absolue : Le contrat fonctionne souvent sur un engagement de volume d’heures défini à l’avance. À chaque atelier hebdomadaire, on fait le point sur le budget consommé (en heures) et on ajuste l’avancement pour s’assurer que les fonctions essentielles rentrent toujours dans l’enveloppe fixée.
- Une réduction drastique du risque d’échec : Le métier testant l’outil chaque semaine, le risque de l’effet tunnel et de la livraison d’un produit inadapté (nécessitant des refontes coûteuses) tombe à zéro. Les pivots ou changements d’avis du client sont intégrés naturellement.
- La garantie de maintenabilité : Bien qu’on ne fasse pas de spécifications a priori, la promesse de livrer un plan de validation, un manuel utilisateur et une documentation exhaustive a posteriori garantit aux équipes informatiques que l’application ne deviendra pas une boîte noire une fois le projet terminé.
FAQ : questions fréquentes
Il est toujours utile de partir d’un premier référentiel d’exigences (objectifs généraux, contraintes techniques, exigences de sécurité). Cependant, la spécification fonctionnelle ultra-détaillée (qui décrit exactement comment chaque bouton doit se comporter, par exemple) n’est plus nécessaire. L’outil No-Code permet de remplacer ce document par un prototype fonctionnel évolutif.
C’est précisément la force de cette organisation. Si le client se rend compte, même après une mise en production, que son processus initial n’est pas adapté à la réalité du terrain, la méthode par ateliers permet de réagir vite. Une modification majeure (pivot) prend généralement deux à trois semaines pour être reconfigurée et déployée, contre plusieurs mois de développements spécifiques dans un modèle classique.
Paradoxalement, non. Bien que le client doive se libérer 2 à 3 heures par semaine pour les ateliers de co-construction, ce temps remplace les longues (et fastidieuses) phases de relecture de spécifications abstraites et les longues phases de recettes en fin de projet. Le temps investi est beaucoup plus qualitatif et efficace.
