Remplacer un workflow sur feuille de calcul par une application : le playbook du week‑end

Ce qui casse quand une feuille de calcul devient un workflow

Les feuilles de calcul sont excellentes pour suivre des choses. Elles s'effondrent quand les gens commencent à les utiliser pour exécuter un processus : les demandes arrivent, des approbations ont lieu, des transferts se font entre équipes, et quelqu'un est censé garder tout cela « correct » manuellement.

Les premières fissures sont souvent invisibles. Deux personnes modifient la même ligne, un filtre cache des enregistrements, et la version « la plus récente » vit dans la pièce jointe d'un email. Ensuite viennent les doublons (« Est‑ce une nouvelle demande ou la même ? »), les formats mélangés (dates, statuts, priorités) et les champs manquants qui étaient « évidents » lors de la création de la ligne.

La propriété devient floue aussi. Si une colonne indique « Assignee » mais que tout le monde peut la changer, il n’y a pas de vraie responsabilité. Quand quelque chose tourne mal, il est difficile de répondre à des questions de base : qui a changé le statut ? Quand est‑il passé en « Done » ? Pourquoi a‑t‑on rouvert la demande ?

Une application en production change les règles. Au lieu d’une grille partagée, vous obtenez des permissions claires, une source unique de vérité, une piste d’audit, et des automatisations (les changements de statut peuvent déclencher des messages et des tâches). Le plus important : le workflow ne dépend plus d’une seule personne vigilante.

Si votre objectif est de remplacer une feuille de calcul par une application en un week‑end, restez réaliste : construisez la première version utilisable, pas le système parfait. « Utilisable » signifie que quelqu’un peut soumettre une demande, qu’une autre personne peut la traiter, et que l’équipe peut voir ce qui est en cours sans courir après les infos.

Décidez ce qui doit être migré maintenant et ce qui peut rester dans la feuille pour un moment. Déplacez les enregistrements centraux et les étapes qui causent le plus de problèmes (intake, statut, responsabilité, dates d’échéance). Laissez le reporting, le nettoyage historique et les champs de cas limite pour plus tard.

Des outils comme AppMaster aident ici parce que vous pouvez modéliser les données, ajouter des écrans basés sur les rôles et configurer des automatisations basiques sans écrire de code, puis itérer après le premier jour.

Choisir le périmètre pour une construction en week‑end

La façon la plus rapide de remplacer un workflow sur feuille de calcul est de garder la première version petite et honnête. Le but n’est pas la perfection. C’est un flux qui fonctionne et que les gens peuvent utiliser lundi sans vous envoyer des SMS.

Écrivez le workflow en étapes simples, comme si vous l’expliquiez à un nouveau coéquipier. Indiquez qui le démarre, qui le révise et ce que « terminé » signifie. Si la feuille a beaucoup d’onglets et de règles annexes, choisissez un chemin principal (le cas 80 %) et ignorez les cas limites pour l’instant.

Ensuite, nommez vos enregistrements centraux. Si vous ne pouvez pas décrire le système avec 3 à 5 noms, c’est trop vaste pour un week‑end. Un tracker ops peut se résumer à Requests, Customers, Approvals et Comments. Tout le reste (tags, pièces jointes, champs spéciaux) peut attendre.

Un périmètre de week‑end qui fonctionne :

• Un type d’enregistrement principal (la chose que vous suivez) et jusqu’à 2 types d’enregistrements de support
• Un jeu de statuts court (3 à 6) qui correspond aux vrais transferts
• Les quelques champs que les gens cherchent ou trient vraiment (propriétaire, date d’échéance, priorité)
• Un écran de création, un écran de liste et un écran de détail
• Une automatisation qui évite le suivi manuel (par exemple une notification sur changement de statut)

Avant de construire quoi que ce soit, rédigez les questions auxquelles l’application doit répondre en quelques secondes : Quel est le statut ? Qui en est responsable ? Qu’est‑ce qui est dû cette semaine ? Qu’est‑ce qui est bloqué, et par qui ? Ces questions vont façonner vos premiers écrans et filtres.

Définissez des critères de succès pour lundi matin afin de savoir quand vous arrêter :

• Moins d’erreurs (pas de cellules écrasées, pas de lignes perdues)
• Transferts plus rapides (responsable clair et prochaine étape)
• Moins de temps passé à mettre à jour le « statut » manuellement
• Une piste d’audit propre (qui a changé quoi et quand)

Si vous construisez dans AppMaster, ce périmètre se traduit bien par un modèle Data Designer rapide, quelques pages basées sur les rôles et un Business Process pour le transfert central.

Nettoyage des données : rendre la feuille importable

Si vous voulez que cela soit fait en un seul week‑end, la victoire la plus rapide est des données propres. La plupart des imports échouent pour des raisons ennuyeuses : formats de date mélangés, « TBD » dans des champs numériques, et trois colonnes qui signifient la même chose.

Commencez par faire une copie de sauvegarde de la feuille et nommez‑la avec la date. Prévoyez ensuite une courte fenêtre de gel pendant laquelle personne ne modifie la feuille (même 30 à 60 minutes aident). Si des modifications doivent continuer, capturez‑les dans un onglet « nouvelles modifications » pour pouvoir les rapprocher plus tard.

Standardisez maintenant chaque colonne pour que l’application puisse la traiter comme un vrai champ :

• Un seul nom de colonne par signification (choisissez « Requester Email », pas « Email/Owner ») et restez cohérent
• Un seul format par colonne (dates YYYY‑MM‑DD, nombres sans séparateurs de milliers, monnaie sans symbole)
• Valeurs autorisées pour les champs style dropdown (Status : New, In Progress, Blocked, Done)
• Champs requis vs optionnels (indiquez ce qui doit exister pour chaque ligne)
• Une seule source de vérité (si deux colonnes sont en désaccord, décidez laquelle prévaut)

Les doublons et les IDs manquants sont un autre blocage courant. Décidez quel est votre identifiant stable (souvent un ID séquentiel ou un UUID généré). Évitez d’utiliser les numéros de ligne comme ID, car les lignes bougent. Si deux lignes représentent la même entité réelle, fusionnez‑les maintenant et notez ce que vous avez changé.

Créez un petit dictionnaire de données dans un nouvel onglet : chaque champ, ce qu’il signifie, un exemple de valeur et qui « le possède » (qui peut dire ce qui est correct). Cela fait gagner du temps quand vous construisez les tables plus tard.

Enfin, marquez quelles colonnes sont calculées versus stockées. Totaux, « jours ouverts » et indicateurs SLA sont généralement calculés dans l’application. Stockez seulement ce dont vous avez besoin pour auditer plus tard (comme la date de demande originale).

Modélisation de la base : traduire les onglets en tables

Une feuille fonctionne parce que tout est dans une grille. Une application fonctionne parce que chaque « chose » devient sa propre table, et ce sont les relations qui font le lien. C’est ici que le désordre se transforme en fondation stable.

Traitez chaque feuille principale comme une table avec une ligne par enregistrement. Évitez les cellules fusionnées, les lignes d’en‑tête vides et les lignes « totaux » dans les données. Tout ce qui est calcul peut être reconstruit plus tard comme vue ou rapport.

Transformer les onglets en tables (et les connecter)

Une règle simple : si une colonne répète le même type de valeur sur de nombreuses lignes, elle appartient à une même table. Si une feuille sert principalement à rechercher des valeurs (comme une liste d’équipes), c’est une table de référence.

Relations courantes, en termes simples :

• Un‑à‑plusieurs : un Customer a plusieurs Requests
• Plusieurs‑à‑plusieurs : une Request peut avoir plusieurs Tags, et un Tag peut être utilisé sur plusieurs Requests (utilisez une table de jonction comme RequestTags)
• Liens « Owner » : une Request a un Assignee (un User), mais un User a beaucoup de Requests assignées

Les listes de référence gardent vos données propres. Créez des tables séparées pour les statuts, catégories, équipes, emplacements ou niveaux de priorité afin que les gens puissent choisir dans une liste plutôt que de taper de nouvelles variantes.

Décider de ce qui nécessite un historique

Les feuilles cachent les modifications. Les apps peuvent les enregistrer. Si les changements de statut comptent, ajoutez une table StatusHistory (RequestId, OldStatusId, NewStatusId, ChangedBy, ChangedAt). Faites de même pour les approbations si vous avez besoin de preuves de qui a approuvé quoi et quand.

Avant de construire dans un outil comme le Data Designer d'AppMaster (PostgreSQL), rédigez une cartographie simple des colonnes de la feuille vers les champs :

• Nom de la feuille -> nom de la table
• En‑tête de colonne -> nom du champ et type (texte, nombre, date)
• Requis vs optionnel
• Valeurs autorisées (table de référence ?)
• Relation (vers quelle table pointe‑t‑elle ?)

Cette carte d’une page évite les surprises à l’import et accélère les étapes suivantes (écrans, permissions, automatisations).

Rôles et permissions : qui peut voir et changer quoi

Les permissions sont le point d’échec des workflows sur feuille. Si tout le monde peut tout modifier, vous obtenez des changements silencieux, des suppressions accidentelles et pas de propriétaire clair.

Commencez par quatre rôles et restez terre‑à‑terre :

• Admin : gère les utilisateurs et les paramètres, et peut corriger les erreurs de données
• Manager : assigne le travail, approuve les changements clés, voit les éléments de son équipe
• Contributor : crée et met à jour les éléments qu’il possède, commente, télécharge des fichiers
• Viewer : accès en lecture seule pour ceux qui ont juste besoin de visibilité

Définissez ensuite des règles d’accès au niveau des lignes en phrases simples :

• Les Contributors voient leurs propres éléments (et tout ce qui leur est assigné)
• Les Managers voient tous les éléments de leur équipe
• Les Admins voient tout
• Les Viewers voient seulement les éléments approuvés/publés (ou un autre sous‑ensemble sûr)

Les approbations sont le filet de sécurité qui rend une nouvelle application digne de confiance. Choisissez 1 ou 2 actions qui doivent être approuvées, et laissez le reste flexible. Choix courants : clôturer une demande, changer une date d’échéance après accord, modifier un champ budget/prix, ou supprimer un élément. Décidez qui approuve (généralement un Manager, avec un Admin en secours) et ce qui se passe quand c’est approuvé (changement de statut, horodatage, nom de l’approbateur).

Une matrice minimale à tester rapidement : les Contributors créent et modifient les éléments Draft et In Progress qu’ils possèdent ; les Managers modifient n’importe quel élément d’équipe et peuvent approuver ; les Viewers ne modifient rien ; les Admins peuvent tout faire, y compris la gestion des utilisateurs.

Si vous utilisez un outil no‑code comme AppMaster, construisez et testez les permissions tôt avec un scénario « mauvais jour » : un Contributor essaie d’éditer l’élément d’un autre, un Viewer tente de changer un statut, et un Manager approuve un changement. Si chaque cas se comporte comme prévu, votre fondation est solide.

Construire les premiers écrans : listes, formulaires et pages de détail

Commencez par les trois écrans que les gens consultent toute la journée : la liste, la page de détail et le formulaire de création/édition. Si ceux‑ci sont rapides et familiers, l’adoption est plus facile.

Les trois écrans centraux (construisez‑les d’abord)

Une bonne page liste répond rapidement à une question : « Que dois‑je traiter ensuite ? » Affichez les colonnes clés que les gens scannent dans une feuille (titre, statut, propriétaire, priorité, date d’échéance), et rendez chaque ligne cliquable.

Sur la page détail, gardez la source unique de vérité lisible. Placez les champs principaux en haut, puis les informations secondaires en dessous. C’est ici que les discussions s’arrêtent car tout le monde regarde le même enregistrement.

Pour le formulaire, visez moins de décisions, pas plus d’options. Groupez les champs, validez les saisies et rendez l’action de soumission évidente.

Rendre l’utilisation rapide : valeurs par défaut, filtres et confiance

La plupart des « apps lentes » donnent cette impression parce qu’elles imposent trop de clics. Définissez des valeurs par défaut sensées (status = New, owner = utilisateur courant, date d’échéance = +3 jours). Indiquez les champs requis avec de courts indices expliquant pourquoi ils sont importants (« Nécessaire pour acheminer l’approbation »).

Les filtres doivent correspondre à de vraies questions, pas à tous les champs possibles. Les plus courants : statut, propriétaire, plage de dates et priorité. Si c’est pertinent, ajoutez un petit résumé en haut (comptes par statut, plus un nombre En retard) pour que les gens obtiennent une valeur en deux secondes.

Ajoutez un simple journal d’activité pour instaurer la confiance : qui a changé quoi, et quand. Exemple : « Priorité changée de Medium à High par Sam à 14:14. » Cela évite les allers‑retours et fluidifie les transferts.

Logique métier : reproduire le workflow sans le chaos

Un « workflow » sur feuille vit souvent dans la tête des gens : qui met à jour quelle colonne, quand, et ce qui compte comme terminé. Dans une application, l’objectif est simple : rendre la prochaine étape évidente et rendre l’étape erronée difficile.

Commencez par cartographier votre processus en statuts clairs. Gardez‑les courts et basés sur l’action :

• Submitted
• In review
• Approved
• Completed
• Escalated

Ajoutez ensuite des règles qui protègent la qualité des données. Rendre certains champs obligatoires (requester, date d’échéance, priorité). Faire respecter les transitions autorisées (on ne peut pas passer de Submitted à Completed directement). Si quelque chose doit être unique, appliquez‑le (comme un numéro de ticket externe).

Dans AppMaster, cette logique s’intègre naturellement dans le Business Process Editor : un bloc par décision, avec des noms clairs. Une bonne habitude est de nommer chaque étape et d’ajouter une phrase d’objectif, par exemple « Approve request : seuls les managers peuvent approuver et cela verrouille les champs de coût. » C’est lisible quand vous revenez dessus plus tard.

Ensuite, définissez des déclencheurs pour que le workflow s’exécute automatiquement :

• À la création : définir le statut par défaut, créer une entrée d’audit, notifier le réviseur
• Au changement de statut : assigner le prochain responsable, définir des horodatages (approved_at), envoyer un message
• Vérifications nocturnes : retrouver les éléments en retard et renvoyer une notification ou escalader

Prévoyez un rollback dès le départ. Si une étape échoue (par exemple, un service de notification est indisponible), ne laissez pas l’enregistrement à moitié mis à jour. Soit arrêtez et affichez une erreur claire avant d’enregistrer les modifications, soit enregistrez le changement d’état mais mettez en file d’attente l’action échouée pour réessai et marquez l’enregistrement « needs_attention ».

Exemple concret : quand une demande passe en Approved, enregistrez d’abord le nom et l’heure de l’approbateur, puis envoyez la notification. Si la notification échoue, l’approbation tient toujours, et l’app affiche une bannière pour renvoyer la notification.

Automatisations et notifications que les gens remarqueront

Le but n’est pas de notifier plus. C’est de notifier seulement quand quelqu’un doit faire quelque chose.

Commencez par choisir les moments qui causent toujours des retards. La plupart des équipes ont besoin de trois ou quatre types de notifications :

• Nouvelle affectation : quelqu’un devient propriétaire et doit agir ensuite
• Approbation requise : un enregistrement est bloqué en attendant qu’une personne précise le révise
• En retard : la date d’échéance est passée et le statut n’est pas terminé
• Commentaire ou mention : quelqu’un a posé une question qui nécessite une réponse

Choisissez les canaux selon l’urgence. L’email convient pour la plupart des mises à jour. Le SMS sert pour les sujets sensibles au temps. Telegram peut bien fonctionner pour la coordination interne rapide. Dans AppMaster, vous pouvez relier ces canaux via des modules de messagerie intégrés déclenchés par des changements de statut ou des échéances.

Rédigez des messages courts et actionnables. Chaque notification doit inclure un identifiant clair pour que le destinataire retrouve l’enregistrement rapidement, même sans lien. Exemple : « REQ‑1842 : approbation d’accès fournisseur requise. Échéance aujourd’hui. Étape actuelle : Security review. »

Pour réduire le bruit, proposez un digest quotidien pour les mises à jour FYI comme les changements de file d’attente ou les éléments dus plus tard dans la semaine. Permettez aux gens de s’inscrire par rôle (approbateurs, managers) plutôt que d’envoyer à tout le monde.

Écrivez aussi des règles pour ne pas notifier :

• Ne pas notifier pour les petites corrections (typos, mise en forme, champs non bloquants)
• Ne pas notifier pendant les imports en masse ou les backfills
• Ne pas notifier quand la même personne a fait le changement et est aussi le destinataire
• Ne pas renvoyer plus d’une fois par jour pour le même élément en retard

Si une notification n’indique pas ce que la personne doit faire ensuite, elle doit aller dans un digest.

Étapes de migration : importer, vérifier et rapprocher

Considérez la migration comme une mini‑release, pas un copier‑coller. Déplacez les données une fois, gardez‑les exactes et assurez‑vous que la nouvelle app corresponde à ce que les gens attendent quand ils l’ouvrent lundi.

Commencez par un petit import de test avant de tout migrer. ExporteZ un CSV de 20 à 50 lignes représentatives, incluant quelques cas sales (cellules vides, dates bizarres, caractères spéciaux). Importez dans vos tables modélisées et confirmez que chaque colonne arrive dans le bon type de champ.

Étape 1 : import de test et cartographie

Après l’import de test, vérifiez trois choses :

• Cartographie des champs : le texte reste du texte, les nombres restent des nombres, et les dates ne se décalent pas d’un jour à cause des fuseaux horaires
• Champs requis : tout ce qui est marqué comme requis dans votre base a effectivement une valeur
• Champs de référence : les IDs et recherches pointent vers de vrais enregistrements, pas des placeholders vides

C’est ici que la plupart des projets de week‑end gagnent ou échouent. Corrigez la cartographie maintenant, pas après avoir importé 5 000 lignes.

Étape 2 : vérifier les relations et rapprocher les totaux

Ensuite, vérifiez que les relations ont du sens. Comparez les totaux entre la feuille et l’app (par exemple Requests et Request Items). Assurez‑vous que les lookups se résolvent et cherchez les enregistrements orphelins (éléments qui référencent une demande inexistante).

Faites des vérifications ponctuelles sur les cas limites : valeurs vides qui doivent devenir null, noms avec des virgules ou des guillemets, notes longues, et formats de date mélangés.

Enfin, traitez l’ambiguïté de la feuille. Si la feuille autorisait « quelqu’un » ou un propriétaire vide, décidez qui possède chaque enregistrement maintenant. Assignez un utilisateur réel ou une file par défaut pour que rien ne reste bloqué.

Quand le test est propre, refaites l’import avec l’ensemble des données. Ensuite rapprochez‑vous : choisissez 10 à 20 enregistrements au hasard et confirmez que l’histoire complète correspond (statut, assigné, horodatages, enregistrements liés). Si quelque chose cloche, faites un rollback, corrigez la cause et réimportez plutôt que de patcher manuellement.

Exemple : transformer un tracker de demandes ops en vraie application

Imaginez un simple tracker de demandes ops qui vivait dans un onglet de feuille de calcul. Chaque ligne est une demande, et les colonnes essaient de tout capturer : propriétaire, statut, notes d’approbation. L’objectif est de garder le même travail, mais rendre la casse plus difficile.

Une version propre de l’app a généralement une table principale (Requests) plus quelques tables de support (People, Teams, StatusHistory, Attachments). Le workflow reste familier : Intake -> Triage -> Approval -> Done. La différence : l’app affiche les bonnes actions à la bonne personne.

Le jour 1, chaque rôle obtient une vue ciblée au lieu d’une grande grille :

• Requester : soumet une demande, voit le statut et les commentaires, ne peut pas modifier après triage
• Triage ops : travaille les files New et Missing info, assigne un propriétaire et une date d’échéance
• Approver : voit seulement Waiting for approval, avec actions approve/reject et notes requises
• Ops owner : voit My work avec les prochaines étapes et une checklist simple

Une automatisation qui remplace le suivi manuel : quand une demande passe en Waiting for approval, l’approbateur reçoit une notification avec le résumé et une action. Si elle reste 24 heures sans réponse, elle est escaladée vers un approbateur de secours ou le lead ops.

Un rapport qui remplace le filtrage de la feuille : une vue weekly Ops load montrant les demandes par statut, le temps moyen dans chaque étape, et les éléments en retard par propriétaire. Dans AppMaster, cela peut être une page dashboard simple alimentée par des requêtes enregistrées.

Les exceptions sont là où les apps rapportent. Plutôt que des modifications ad hoc, rendez‑les explicites :

• Demande rejetée : statut Rejected, raison obligatoire, demandeur notifié
• Données manquantes : triage renvoie en Needs info avec une question requise
• Réaffectation : changement de propriétaire, journalisé dans l’historique et notification du nouveau propriétaire

Checklist de mise en production et prochaines étapes

Le jour du lancement porte moins sur les fonctionnalités que sur la confiance. Les gens migrent quand l’accès est correct, les données ont l’air justes et il y a un moyen clair d’obtenir de l’aide.

Checklist de mise en production (à faire avant l’annonce)

Suivez une checklist stricte pour ne pas passer le lundi à réparer :

• Permissions testées pour chaque rôle (voir, éditer, approuver, admin) avec des comptes réels
• Sauvegarde prise de la feuille originale et des fichiers d’export importés
• Import confirmé : nombre d’enregistrements concorde, champs requis remplis, IDs uniques
• Notifications validées de bout en bout (email/SMS/Telegram) : bons déclencheurs, bons destinataires, formulation claire
• Plan de rollback documenté : mettre en pause les nouvelles entrées, réimporter ou revenir en arrière

Après cela, faites des tests de fumée comme le ferait un nouvel utilisateur. Créez un enregistrement, modifiez‑le, faites‑le passer en approbation, recherchez‑le et exportez une vue filtrée. Si des gens utiliseront des téléphones, testez l’accès mobile pour les deux ou trois actions les plus fréquentes (soumettre, approuver, vérifier le statut).

Faciliter l’adoption en 15 minutes

Gardez la formation courte. Parcourez une fois le chemin heureux, puis distribuez une feuille de triche d’une page qui répond : « Où saisir une demande ? », « Comment voir ce qui m’attend ? », et « Comment savoir que c’est fini ? »

Mettez en place un plan de support simple pour la première semaine. Choisissez un responsable pour répondre aux questions, une personne de secours, et un endroit pour signaler les problèmes. Demandez aux rapporteurs d’inclure une capture d’écran, l’ID de l’enregistrement et ce qu’ils attendaient.

Une fois l’app stable, planifiez de petites améliorations basées sur l’usage réel : ajouter des rapports basiques (volume, temps de cycle, goulots d’étranglement), renforcer la validation là où les erreurs persistent, connecter les intégrations que vous avez laissées de côté (paiements, messagerie, autres outils) et réduire les notifications pour qu’elles soient moins nombreuses et plus ciblées.

Si vous voulez construire et lancer rapidement sans codage intensif, AppMaster (appmaster.io) est une option pratique pour modéliser une base PostgreSQL, créer des écrans web et mobiles basés sur les rôles, et configurer des automatisations de workflow au même endroit.