Méthode, Application métier

D'un Excel partagé à un SaaS interne : cadrer le MVP

La méthode en quatre semaines pour transformer le fichier Excel critique de votre entreprise en application interne : cartographier l'usage réel, définir le MVP, poser les droits et organiser la cohabitation.

Par Yanis Zedira. Publié le 30 août 2026. 11 min de lecture.

Pour transformer un Excel partagé en application interne, on ne recopie pas le fichier : on cadre un MVP autour des trois ou quatre usages qui comptent vraiment, on les livre en quelques semaines, et on laisse le reste dans le tableur pendant la transition. Le fichier Excel n'est pas le cahier des charges, c'est le symptôme.

Cet article décrit un cadrage en quatre semaines, une semaine par étape : cartographier l'usage réel, définir le MVP en termes d'usage, modéliser les entités et dessiner les écrans, puis arbitrer les intégrations. À la fin, vous avez un périmètre écrit, court, chiffrable, et une liste assumée de ce que vous abandonnez. Le guide du cahier des charges de site internet traite le cadrage d'un projet web classique, cet article se concentre sur le cas particulier du tableur métier que l'on internalise.

Pourquoi un Excel partagé finit-il par devenir un risque ?

Parce qu'il grandit sans jamais être remis à plat. Personne ne décide un jour de construire un système critique dans un tableur. Il se construit tout seul, par ajouts successifs, et le jour où il devient indispensable, plus personne n'ose y toucher.

Quatre symptômes reviennent presque systématiquement. Les macros empilées, écrites par des personnes différentes sur plusieurs années, dont plus personne ne connaît le déclenchement exact. Les onglets morts, gardés au cas où, qui alimentent encore trois formules quelque part. Les exceptions non écrites, ces règles que l'on applique de tête et qui ne figurent nulle part : le client qui a un tarif particulier, la commande que l'on saisit deux fois, le mois de décembre que l'on calcule autrement. Et surtout la dépendance à une seule personne, celle qui sait pourquoi la colonne AF ne doit jamais être triée.

Le signal qui doit déclencher le chantier n'est pas la taille du fichier. C'est le moment où l'entreprise commence à organiser son travail autour des limites du tableur plutôt que l'inverse : on attend que quelqu'un ferme le fichier, on s'interdit de modifier certaines cellules, on refait des saisies pour ne pas casser une formule.

Semaine 1 : comment cartographier l'usage réel plutôt que le fichier ?

L'erreur de départ consiste à ouvrir le classeur et à documenter les onglets. Vous documenterez alors une accumulation d'accidents. La bonne unité d'analyse est la personne et son geste, pas la feuille de calcul.

Concrètement, prenez chaque personne qui touche au fichier et notez, pour une semaine réelle : ce qu'elle vient y chercher, ce qu'elle y saisit, à quel moment, et ce qu'elle fait juste avant et juste après. Vous découvrirez presque toujours que le fichier sert à trois ou quatre choses distinctes, qui n'ont pas la même urgence ni les mêmes utilisateurs. Vous découvrirez aussi des usages fantômes : des colonnes remplies par habitude que personne ne lit depuis deux ans.

Posez systématiquement deux questions. Que se passe-t-il si cette information est fausse, et qui s'en aperçoit ? Que faites-vous quand le cas ne rentre pas dans la grille ? La seconde question fait sortir les exceptions non écrites, qui sont la vraie matière du projet. C'est la même logique que celle de l'audit de trente minutes pour cartographier les pertes cachées, appliquée à un seul outil.

Semaine 2 : comment définir le MVP en termes d'usage et non de fonctionnalités ?

Un MVP défini par fonctionnalités s'allonge indéfiniment, parce qu'une fonctionnalité en appelle toujours une autre. Un MVP défini par usages s'arrête tout seul, parce qu'un usage se termine.

La formulation qui marche tient en une phrase par usage : telle personne doit pouvoir faire telle chose, dans tel délai, sans demander à personne. Par exemple : le commercial doit pouvoir créer une affaire et la retrouver le lendemain sans ouvrir le tableur. Ou : l'atelier doit pouvoir voir les commandes du jour triées par échéance, sur un écran, sans filtrer quoi que ce soit.

Le second travail de cette semaine est le plus inconfortable : décider ce que l'on abandonne. Reprendre l'Excel à l'identique est la garantie de reproduire ses défauts avec un budget de développement en plus. Le passage à une application est l'unique occasion de simplifier, parce que c'est le seul moment où tout le monde accepte de rediscuter les règles.

Semaine 3 : quelles entités identifier et comment dessiner les écrans ?

Une application repose sur des objets métier, pas sur des lignes. La semaine 3 consiste à nommer ces objets et à décider ce qui les relie.

Dans la plupart des tableurs métier, on retrouve quatre à six entités : un client ou un tiers, une affaire ou une commande, une ligne de détail, une intervention ou une tâche, un document. Le test qui valide un découpage est simple : chaque entité doit avoir une identité propre et une durée de vie propre. Si vous ne savez pas dire quand un objet naît et quand il meurt, ce n'est pas une entité, c'est un attribut.

Les écrans découlent directement des usages de la semaine 2 : un écran par usage principal, avec le geste dominant visible sans défilement. Une règle de terrain utile : un écran qui demande à l'utilisateur de choisir entre plus de cinq actions n'est pas un écran, c'est un menu déguisé.

Deux sujets se posent maintenant et non plus tard. Les droits d'abord : qui voit quoi, qui saisit, qui valide, qui exporte. Dans un tableur, ces distinctions n'existent pas, et leur apparition change parfois l'organisation du travail : il faut donc en parler tôt. Les validations ensuite : quelles règles empêchent une saisie incohérente, et lesquelles se contentent d'un avertissement. Trop de blocages et les utilisateurs contournent l'outil, trop peu et vous reproduisez le tableur. Le détail de cette phase de conception est décrit dans notre offre de développement SaaS et applications métier.

Semaine 4 : quelles intégrations garder, et que peut-on laisser manuel ?

La quatrième semaine tranche les connexions avec le reste du système d'information : comptabilité, facturation, paie, outil commercial, messagerie. C'est le poste qui fait exploser les budgets quand il n'est pas arbitré.

Classez chaque intégration selon deux critères : la fréquence de l'échange et le coût de l'erreur. Une exportation mensuelle vers la comptabilité peut rester manuelle sans dommage. Une synchronisation quotidienne du stock ne le peut pas. Entre les deux, la question est de savoir combien de minutes par semaine la manipulation coûte et combien l'automatiser coûterait à construire puis à maintenir.

Il est parfaitement acceptable de lancer une application avec des échanges manuels. Ce qui ne l'est pas, c'est de ne pas l'avoir décidé. Écrivez explicitement, dans le périmètre : cette liaison sera faite à la main au lancement, elle sera automatisée en version 2 si le volume le justifie. Les principes de priorisation détaillés dans notre approche de l'automatisation IA s'appliquent tels quels ici.

Comment faire cohabiter l'Excel et l'application pendant la transition ?

La cohabitation est inévitable et doit être organisée, sinon elle s'installe pour toujours. La règle unique qui la rend supportable : une seule source de vérité par donnée, à tout moment.

En pratique, on découpe par usage et non par période. Dès que l'application prend en charge un usage, cet usage sort du tableur, complètement. Le fichier reste pour ce qu'il gère encore, et l'on passe le reste en lecture seule. Ce qui ne fonctionne jamais, c'est la double saisie temporaire, censée durer un mois : elle dure six mois, produit deux vérités divergentes et discrédite l'application.

Fixez une date de bascule pour chaque usage et une date de gel du fichier. Le gel signifie que le classeur devient consultable mais non modifiable, archivé, avec une personne désignée pour répondre aux questions historiques. Prévoyez aussi le cas de retour arrière : si l'application pose problème la première semaine, que fait-on ? Écrire cette procédure prend une heure et retire beaucoup d'angoisse aux équipes.

Ce que je vois le plus souvent chez un client

L'erreur la plus fréquente n'est pas technique. C'est de confondre le fichier avec le besoin. On me transmet un classeur de vingt onglets avec la demande de le reproduire, et si on le fait, on livre une application qui coûte cher et qui reproduit fidèlement des règles que plus personne ne défend. Dans les cadrages que nous menons, la moitié environ des colonnes d'un tableur historique disparaissent sans que quiconque les réclame ensuite.

Le deuxième schéma récurrent tient à la personne qui détient le fichier. Elle a souvent construit ce tableur seule, avec ingéniosité, et le projet peut être vécu comme une mise en cause de son travail. Quand cette personne n'est pas associée dès la semaine 1, elle devient, souvent sans le vouloir, le meilleur frein du projet : les exceptions non écrites ne remontent jamais. Quand elle est associée et reconnue comme référente métier, le cadrage va deux fois plus vite.

Le troisième point que je corrige presque à chaque fois concerne les droits. Dans un tableur, tout le monde peut tout. En passant à une application, on découvre que certaines personnes validaient des choses qu'elles n'auraient pas dû valider, et d'autres attendaient une validation qui n'existait pas. Ce sujet doit être traité comme une décision d'organisation, avec la direction, pas comme un paramétrage technique en fin de projet.

Passer à l'action

Ouvrez votre fichier et faites un seul exercice, aujourd'hui. Listez les personnes qui l'utilisent, et pour chacune, écrivez en une phrase ce qu'elle vient y faire. Si vous obtenez plus de six phrases différentes, votre tableur porte plusieurs applications à la fois, et le découpage du MVP commence là. Si vous ne parvenez pas à écrire ces phrases sans demander à quelqu'un, vous avez déjà identifié votre dépendance principale.

Pour cadrer ce périmètre avec un regard extérieur, réservez un appel de trente minutes ou passez par le calendrier de YZ Automation. Nous regardons le fichier, les usages et les volumes, et vous repartez avec un périmètre de version 1 écrit et une estimation, même si vous le développez ensuite sans nous.