Application mobile no-code : dans quels cas est-ce un bon choix ?

Oui, une application mobile no-code peut être un bon choix, à condition de savoir ce que vous achetez. Un outil no-code permet d’assembler des écrans, des formulaires et des règles simples sans écrire de code, sur une plateforme qui héberge l’application et ses données. C’est un bon moyen de vérifier qu’un usage existe. Ce n’est pas une manière de faire disparaître la conception, la sécurité ou la maintenance : ces sujets changent seulement de place.

Cet article vous aide à situer votre projet : ce que le no-code fait bien, les signaux qui annoncent ses limites, et les questions à poser avant de construire dessus.

No-code, low-code, développement : de quoi parle-t-on ?

Les trois termes décrivent un degré de liberté, pas un niveau de qualité.

• No-code : l’application se configure dans l’éditeur visuel d’une plateforme. Ce que la plateforme n’a pas prévu est en général difficile, voire impossible, à obtenir.
• Low-code : la plateforme reste visuelle, mais accepte du code pour les cas particuliers, par exemple une règle de calcul ou un connecteur vers un autre logiciel.
• Développement : l’équipe écrit l’application avec des langages et des bibliothèques ouverts. Presque tout est possible, mais tout est à concevoir, tester et maintenir.

Le choix ne se fait pas une fois pour toutes. Un même projet peut commencer sur une plateforme pour vérifier l’usage, puis passer en développement quand les règles deviennent stables et nombreuses. Encore faut-il avoir prévu ce passage dès le départ.

Les situations où le no-code a du sens

Le no-code est pertinent quand la question principale n’est pas technique mais d’usage : les équipes vont-elles vraiment se servir de l’outil ? Quelques situations typiques, à titre d’exemple :

• un outil interne simple : une liste de contrôle, un formulaire de visite, un annuaire, un suivi de demandes à quelques statuts ;
• un prototype à mettre entre les mains de quelques utilisateurs pour observer ce qu’ils font réellement ;
• une opération limitée dans le temps, où l’application n’a pas vocation à durer ;
• un processus encore mouvant, dont les règles changeront plusieurs fois avant d’être fixées.

Dans ces cas, la facilité de modification compte plus que la finesse de l’outil. Une personne de l’équipe peut ajuster un champ ou un écran sans attendre un cycle de développement, ce qui est précieux tant que l’on apprend.

Les signaux qui annoncent les limites

Les difficultés apparaissent rarement le premier mois. Elles arrivent quand l’outil devient central et que l’entreprise commence à en dépendre. Soyez attentif aux signaux suivants :

• des règles métier qui s’accumulent en contournements : champs cachés, automatisations en chaîne, calculs dupliqués ;
• un besoin de fonctionner sans réseau, sur un chantier ou en sous-sol, avec une synchronisation fiable au retour de la connexion ;
• des échanges réguliers avec un ERP, un CRM ou un logiciel comptable qui dépassent ce que proposent les connecteurs de la plateforme ;
• des droits d’accès fins, par exemple une information visible par un responsable mais pas par un intervenant ;
• un abonnement dont le prix dépend du nombre d’utilisateurs, de données ou d’opérations, à recalculer à chaque étape de croissance.

Aucun de ces signaux n’impose à lui seul d’abandonner le no-code. Plusieurs d’entre eux réunis indiquent en revanche que l’outil est devenu un logiciel métier à part entière, et qu’il mérite d’être traité comme tel : règles écrites, tests, sauvegardes, évolutions planifiées.

Publier sur les stores : une étape à anticiper

Beaucoup de plateformes no-code produisent des applications web. Pour une application installable depuis l’App Store ou Google Play, vérifiez ce que la plateforme permet réellement et qui soumet l’application. Les consignes de validation d’Apple précisent qu’une application doit apporter davantage qu’un site web reconditionné (règle 4.2), et que les applications créées avec un service de génération d’applications sont refusées si elles ne sont pas soumises directement par le fournisseur du contenu (règle 4.2.6).

Autrement dit, votre entreprise doit en principe publier sous son propre compte, et l’application doit rendre un service réel. Si votre besoin se limite à consulter et saisir des informations, une application web ouverte depuis le téléphone peut suffire : nous détaillons cet arbitrage dans notre article application web ou application mobile : comment choisir.

Données, dépendance, sortie : les questions à poser avant de construire

Avec une plateforme no-code, vos données et la logique de votre application sont hébergées chez un éditeur. Lorsque des données personnelles sont en jeu (clients, salariés, intervenants), cet éditeur agit en principe comme sous-traitant au sens du RGPD : le traitement doit être encadré par un contrat, et ce contrat doit prévoir, au choix du responsable du traitement, la suppression ou la restitution des données au terme de la prestation. Cela se vérifie dans les conditions contractuelles de l’éditeur, pas dans sa page commerciale ; la lecture juridique relève d’un conseil compétent.

Posez aussi ces questions pratiques, et gardez les réponses par écrit :

1. Où les données sont-elles hébergées, et puis-je les exporter dans un format réutilisable ?
2. La logique de l’application (écrans, règles, automatisations) peut-elle être exportée, ou n’existe-t-elle que dans la plateforme ?
3. Comment les droits d’accès sont-ils définis, et peut-on retirer un accès immédiatement ?
4. Que devient l’application si l’éditeur change ses tarifs, ses conditions ou retire une fonctionnalité ?
5. Qui, dans l’entreprise, est responsable de l’outil : modifications, sauvegardes, comptes utilisateurs ?

Si la logique ne peut pas être exportée, passer plus tard au développement signifie reconstruire l’application. Ce n’est pas rédhibitoire, mais c’est un coût à connaître avant de s’engager, pas à découvrir au moment de partir.

Une démarche prudente en trois temps

D’abord, décrire l’usage. Qui utilise l’application, où, avec quel appareil, et pour faire quoi ? Quelles informations entrent, lesquelles sortent, et vers quels autres outils ? Cette description reste valable quelle que soit la technologie retenue.

Ensuite, tester petit. Un premier périmètre, quelques utilisateurs, une durée définie et des critères d’observation fixés à l’avance : l’outil est-il utilisé, que contournent les équipes, qu’est-ce qui manque ? Ne migrez pas tout un processus sur la plateforme avant d’avoir ces réponses.

Enfin, décider en connaissance de cause. Si l’outil remplit son rôle et que les limites ne sont pas atteintes, rester sur la plateforme est un choix légitime. Si les signaux s’accumulent, les règles observées pendant le test deviennent la base d’un cahier des charges pour une application mobile développée pour votre usage ou pour une application web. Le test n’aura pas été perdu : il aura servi à savoir quoi construire.

Dans les deux cas, prévoyez qui fera évoluer l’outil après sa mise en service. C’est le sujet de notre article sur la maintenance évolutive d’une application d’entreprise.