Développer sa propre application terrain avec l'IA générative : bonne ou mauvaise idée ?

Rien de plus simple pour un responsable logistique que de décrire son besoin en une phrase à Claude, ChatGPT ou Gemini. Trente secondes plus tard, une interface apparaît : des champs, un bouton « valider », un document à joindre. Ça fonctionne. Le formulaire papier est mort et personne n'a eu besoin d'appeler la DSI.

Ce scénario n'est plus une anecdote isolée. Il se répète aujourd'hui dans un nombre croissant d'entreprises équipées d'outils d'IA générative grand public. Le réflexe est logique : pourquoi attendre six mois et négocier un budget de développement quand un prompt suffit à obtenir un résultat visible en quelques minutes ? En effet, l'utilisation de l'IA générative a presque doublé au cours des six derniers mois, 75 % des travailleurs du savoir à l'échelle mondiale y ayant recours 1.

La preuve : ce scénario s'est joué à grande échelle chez un leader européen de la logistique. Des équipes non techniques ont commencé à créer elles-mêmes leurs propres apps et tableaux de bord avec Gemini, sans attendre de validation formelle. Interrogée sur le sujet, la direction informatique du groupe n'a jamais mis en doute la capacité de ses équipes à produire ces outils.

Sa préoccupation ne portait pas sur la capacité à construire ces applications, mais sur la gouvernance et la consolidation des données : des dizaines d'artefacts non gouvernés, une donnée qui ne remonte nulle part, rien qui ne survive à son auteur.

Le diagnostic du directeur des systèmes d'information a été sans détour : un outil bâti seul avec une IA générative grand public peut être copié par n'importe qui d'autre… mais il ne peut pas être gouverné. Ce qu'une DSI peut, en revanche, accepter, c'est une intelligence artificielle s'appuyant sur une plateforme gouvernée.

Coder n'a jamais été la partie la plus difficile

Vous l'avez sans doute déjà constaté, peut-être même testé vous-même : décrivez votre besoin à Claude, ChatGPT ou Gemini, et vous obtenez une application qui fonctionne. Ce n'est pas la question, et ça ne va pas devenir moins vrai avec le temps : les modèles d'IA générative progressent d'une version à l'autre, tous les trois à quatre mois environ, et l'écart qui subsiste entre le code écrit par l'IA et le code écrit à la main continue de se réduire.

La réalité est que coder une application n'a jamais été l'étape la plus difficile d'un projet de digitalisation terrain. C'est certes l'étape la plus visible, celle qu'on peut filmer dans une démo de trois minutes. Mais cela ne signifie pas qu'elle est la plus déterminante.

Pourquoi ? Parce qu'une app mobile, pour une équipe opérationnelle, ne consiste pas à proposer un écran qui s'affiche une seule fois. C'est un objet qui doit survivre à l'usure : au départ de son auteur, à un entrepôt sans réseau, à une mise à jour du système d'exploitation du smartphone, à un audit de sécurité, à trois ans de croissance de l'entreprise, etc. Or, le code généré en un prompt ne répond à aucune de ces questions. Il les pose, simplement, un peu plus tard, souvent au pire moment, quand plus personne n'est là pour y répondre.

L'iceberg caché sous chaque application « faite maison »

Une IA générative produit un résultat visible en quelques minutes : c'est la partie émergée de l'iceberg, soit environ 20 % de ce qui fait qu'une app terrain fonctionne réellement, dans la durée, à l'échelle d'une organisation. Les 80 % restants se trouvent sous la ligne de flottaison, invisibles dans la démo, et c'est précisément ce que les développeurs sous-estiment le plus.

La gouvernance et le risque de l'homme-clé

Une application construite par une seule personne, avec son propre compte Claude, Gemini ou ChatGPT ne laisse aucune trace exploitable par l'organisation. Pas de cahier des charges. Pas de documentation. Pas de second responsable capable de reprendre la main en cas de besoin. Sa seule mémoire vive est l'historique de conversation d'un individu.

Tant que le collaborateur reste dans l'entreprise, l'application vit. Le jour où il change de poste ou quitte la société, l'app devient orpheline : plus personne n'ose la modifier, encore moins la faire évoluer, de peur de casser un mécanisme que personne ne comprend vraiment.

À l'échelle d'une organisation, il faut multiplier ce scénario par chaque collaborateur qui, un soir, a voulu tester un prompt pour résoudre son propre problème métier.

C'est précisément le phénomène anticipé par Gartner 3 dès 2021 :

Cette dynamique n'a rien d'anecdotique : chaque application créée hors du regard de l'IT est un silo de données supplémentaire, une source de reporting supplémentaire qui ne remonte nulle part, et un nouveau risque de conformité que personne n'a évalué.

Voici le constat qui a fait basculer la réflexion d'une DSI, du build interne vers une plateforme gouvernée :

Une app pensée au bureau ne survit pas sur le terrain

Une IA générative grand public produit ce qu'elle connaît le mieux : des interfaces de type « logiciel de bureau » – des champs à remplir, des cases à cocher, du texte à taper. C'est presque l'inverse de ce dont un technicien, un livreur ou un auditeur QHSE a besoin sur le terrain.

Un opérateur en entrepôt porte des gants. Un technicien travaille en plein soleil, sur un écran à peine lisible. Un livreur tient un colis d'une main et son téléphone de l'autre. Aucun d'entre eux n'a ni le temps ni les mains libres pour remplir un formulaire conçu comme un tableur.

Ce que le terrain exige, c'est l'inverse d'une saisie manuelle :

• Une capture guidée où un scanner de codes-barres ;
• Une reconnaissance OCR ou un scanner vision qui remplace la frappe ;
• Un outil où chaque étape est pensée pour être accomplie en deux secondes avec un seul doigt, et non avec un clavier et un paragraphe.

Cette ergonomie ne s'improvise ni en un prompt ni depuis un bureau. Elle s'appuie sur des années d'observation d'équipes opérationnelles au contact du terrain.

À cela s'ajoute une question tout aussi critique : la fiabilité en conditions réelles. Une démo s'exécute sur le Wi-Fi du siège. Le terrain, lui, comprend des sous-sols d'entrepôt sans réseau, des tournées rurales en zone blanche et des équipes qui ne peuvent pas s'arrêter de travailler parce qu'une requête a expiré. Le mode hors ligne n'est pas une fonctionnalité qu'on ajoute après coup : c'est une architecture entière – stockage local, file de synchronisation, gestion des conflits, reprise sur erreur partielle – qui ne se prompte pas non plus. Elle se construit.

Mises à jour, distribution, intégrations, sécurité : le reste de l'iceberg

Ces deux premiers points sont ceux que les décideurs opérationnels sous-estiment le plus. Mais l'iceberg est bien plus impressionnant encore sous la ligne de flottaison.

En effet, déployer une application développée en interne sur 50, 200 ou 1 000 terminaux terrain suppose de créer un compte développeur, de la lister sur l'App Store (iOS) ou le Google Play Store, et de passer par leurs cycles de validation à chaque évolution, ou de gérer une distribution MDM en entreprise, avec, dans tous les cas, une signature d'application et un versioning propre.

La maintenir suppose :

• De pousser une nouvelle version sans supprimer les droits des utilisateurs actifs ;
• D'absorber une mise à jour du système d'exploitation qui casse une dépendance ;
• De corriger une faille de sécurité qui ne peut pas attendre le prochain sprint.

Sur une plateforme gouvernée, rien de tout cela n'est un nouveau projet : l'application est déjà installée, et une nouvelle version s'apparente à un simple changement de configuration et non à une nouvelle soumission aux stores.

De même, une app qui ne communique avec aucun système se contente d'être un simple formulaire : sans connexion à l'ERP, au WMS ou aux outils de pilotage, les données collectées ne consolident rien. Elle s'ajoute alors à la pile de ressaisies manuelles que l'application était pourtant censée éliminer. Et l'intégration est précisément le chantier que le « do it yourself » ne termine jamais : authentification, limites de débit, gestion des erreurs, évolution des schémas de données, supervision… La liste s'allonge à mesure que le système grandit.

Sécurité et conformité complètent le tableau : hébergement, chiffrement, gestion des accès par profils, piste d'audit, certifications (ISO 27001, SOC 2…). Rien de tout cela n'est un détail pour une DSI dans un secteur réglementé comme celui de l'énergie, de la santé, des transports ou de la finance.

C'est pourquoi WizyVision est certifiée ISO 27001 ! Nous détaillerons ce sujet dans un prochain article consacré à la sécurité et à la conformité.

En d'autres termes, les apps « maison », une fois créées, non seulement engendrent un certain nombre de risques, mais nécessitent aussi l'implication de l'équipe IT pour les maintenir, les sécuriser, en vérifier la conformité, les faire évoluer, etc. Équipe qui, le plus souvent, n'est pas à l'origine de sa création. Soit une charge de travail supplémentaire.

Le vrai test : que devient le code un an après ?

Admettons, pour les besoins du raisonnement, que le code généré fonctionne parfaitement le premier jour. Encore faut-il qu'il tienne dans la durée.

Ce constat s'applique aux équipes dotées de revues de code, d'outils de qualité et de processus de validation. Il est nécessairement plus sévère pour une application générée par un collaborateur métier seul dans son coin, sans second regard, sans discipline de dépôt, sans revue. Le code fonctionne le jour 1. Ce qui se dégrade, silencieusement, c'est tout ce qui n'a pas de propriétaire.

Une étude publiée en juillet 2026 par GitClear et GitKraken 6, portant sur 623 millions de modifications de code réelles entre 2023 et 2026, apporte un éclairage précieux, y compris pour des équipes de développeurs professionnels, outillées et disciplinées.

Le coût réel ne se lit jamais dans la démo

La recherche en génie logiciel converge, depuis des décennies, vers un même constat : le développement initial n'est jamais la part dominante du coût d'un logiciel au cours de sa durée de vie. Plusieurs analyses du secteur du génie logiciel convergent vers un même ordre de grandeur : la maintenance représenterait 50 à 80 % du coût total d'un logiciel sur son cycle de vie, contre 20 à 50 % pour le développement initial selon les contextes 4.

Le Standish Group 5 documente un phénomène voisin dans son CHAOS Report :

Aucune de ces charges n'apparaît dans une démo de prompt. Elles apparaissent toutes, une à une, dans les mois qui suivent le lancement : sous forme de tickets, de correctifs urgents, de demandes d'évolution que personne ne sait vraiment traiter. Le collaborateur le plus à l'aise avec le prompt devient, de fait, le responsable permanent de la maintenance d'une app qu'il n'avait jamais prévu d'entretenir. Ce qui n'est écrit dans aucune fiche de poste.

Le même prompt, un « j+1 » radicalement différent

Comme précisé précédemment : l'intelligence artificielle sait très bien coder. C'est pourquoi la console d'administration WizyVision permet de générer une application à partir d'une simple description en langage naturel. L'instinct du prompt est le bon. Ce qui change tout, c'est ce sur quoi il s'appuie.

Deux prompts identiques, deux résultats radicalement différents selon ce sur quoi ils s'appuient.

Envoyé à une IA générative seule, sans plateforme derrière elle, un prompt qui génère du code brut vous laisse tout ce qui se trouve sous la ligne de flottaison :

• La synchronisation hors ligne ;
• La distribution ;
• Les mises à jour ;
• Les permissions ;
• Les intégrations ;
• La gouvernance…

Tout cela devient votre problème, à construire vous-même, pièce par pièce, sans filet.

Mais envoyé à la console WizyVision, ce même prompt atterrit, à l'inverse, dans un environnement où le mode hors ligne, la distribution, les permissions, les intégrations et la gouvernance existent déjà. La configuration devient alors la documentation : l'application est un schéma déclaratif – champs, règles, workflows, statuts – lisible et modifiable par toute personne autorisée, et non du code dont la compréhension repose sur la mémoire d'un seul auteur. Le contrôle d'accès, les rôles et la piste d'audit sont centralisés une fois pour toutes, et non réinventés à chaque projet.

Même prompt. Même instinct de départ. Mais un jour 2 radicalement différent.

Comparatif : application générée seule vs application générée sur une plateforme gouvernée

Pourquoi privilégier une plateforme robuste plutôt qu'une application générée en interne par l'intelligence artificielle ? Voici, critère par critère, ce qui distingue une app issue d'un prompt isolé d'une application issue du même prompt, mais déployée sur une plateforme conçue pour les opérations de terrain.

Quand construire soi-même son application avec l'IA a du sens

Néanmoins, il existe des situations où prompter sa propre app est le bon choix :

• Un vrai one-shot, utilisé une seule fois pour un besoin ponctuel ;
• Un outil interne jetable, sans ambition de survivre au trimestre ;
• Une tâche sans composante terrain, sans exigence hors ligne, pour remplacer Excel.

Dans ces cas précis, le temps et l'argent qu'exigerait une plateforme ne se justifient pas nécessairement. La question à vous poser n'est donc pas de savoir si l'intelligence artificielle peut construire cette application, car la réponse est oui dans la plupart des cas.

L'enjeu est de vous demander si « cette app doit survivre à son auteur, aux exigences terrain, à l'année prochaine… » Si la réponse à cette question est oui, la partie difficile commence exactement là où le prompt s'arrête.

Conclusion : coder n'a jamais été le plus dur

Les plateformes no-code de nouvelle génération et l'IA générative grand public ont un point commun : elles ont rendu accessible à tout collaborateur opérationnel la création d'une première version d'une application. Ce n'est pas un problème à combattre. C'est un signal à écouter.

Si vos équipes terrain commencent déjà à prompter leurs propres outils, ce n'est pas de la désobéissance : c'est la preuve qu'un besoin réel existe et que l'instinct de vos collaborateurs est le bon. L'idée n'est pas de les en empêcher, mais de leur fournir une solution solide sur laquelle ce prompt peut construire une app pérenne, c'est-à-dire gouvernée, robuste sur le terrain, connectée au reste du système d'information et qui survit à son auteur.