D'une boîte mail partagée à une application métier complète

Le projet en 30 secondes

1. Au départ, il y avait simplement une boîte mail

Ce projet ne commence pas avec une application, du code ou une réflexion sur le choix d'une technologie.

Il commence avec une boîte mail.

Les missions destinées aux équipes terrain étaient envoyées sur une adresse partagée. Plusieurs personnes surveillaient cette même boîte, récupéraient les missions et se les répartissaient.

Le système fonctionnait. Mais pour comprendre ce qui se passait réellement, il fallait souvent ouvrir les emails.

Qui a pris cette mission ? Quelqu'un a-t-il déjà répondu ? Où en est-elle ? Est-ce terminé ? Qui s'en occupe ?

Quand l'information n'était pas suffisamment claire dans la conversation, la solution la plus simple restait de s'appeler.

Le problème existait également dans l'autre sens. Les équipes opérationnelles envoyaient les missions de livraison, puis devaient suivre les échanges pour comprendre leur avancement.

La boîte mail n'était donc plus seulement un outil de communication.

Elle était devenue, par défaut, un outil de dispatch, de suivi et presque de gestion des missions.

Et ce n'est pas vraiment ce pour quoi une boîte mail est conçue.

2. Le vrai problème n'était pas l'email

La première question aurait pu être :

« Comment mieux organiser cette boîte mail ? »

Mais cela aurait seulement amélioré le fonctionnement existant.

Le vrai problème était ailleurs : une partie du processus de dispatch reposait sur les personnes elles-mêmes.

Il fallait recevoir l'information, comprendre à qui elle était destinée, se répartir le travail, informer les autres, suivre l'avancement et conserver une trace de ce qui avait été fait.

Une réponse naturelle aurait été d'ajouter davantage de coordination humaine pour centraliser les demandes et les distribuer.

C'est à ce moment-là que le projet est devenu intéressant.

Si cette personne devait principalement recevoir de l'information, la structurer, la transmettre aux bonnes personnes et suivre son évolution, pouvait-on construire un système capable de prendre en charge une grande partie de ce travail ?

L'objectif n'était donc pas de créer une application pour créer une application.

L'objectif était de repenser le processus avant d'ajouter une nouvelle couche humaine pour le faire fonctionner.

3. Avant de développer, il fallait comprendre le métier

Très rapidement, une chose est devenue évidente : remplacer une boîte mail demande de comprendre tout ce qu'elle permettait de faire, même implicitement.

Il fallait notamment déterminer :

• comment une mission est créée ;

• quelles informations sont nécessaires ;

• qui doit la voir ;

• comment un membre de l'équipe indique qu'il la prend en charge ;

• comment les autres savent qu'elle est déjà attribuée ;

• quelles étapes une mission traverse ;

• quelles informations doivent remonter aux opérations ;

• quelles preuves doivent être conservées ;

• comment une mission est considérée comme terminée.

C'est progressivement qu'une logique beaucoup plus simple est apparue.

Une mission pouvait être à faire, puis être prise en charge, devenir en cours, puis être terminée.

Chaque changement devait être visible des deux côtés.

L'équipe terrain devait savoir ce qu'elle avait à faire.

Les opérations devaient savoir ce qui était en train d'être fait.

Et personne ne devait avoir besoin d'appeler quelqu'un simplement pour savoir où en était une mission.

Cette étape paraît simple une fois le système construit.

En réalité, elle a conditionné presque tout le reste du projet.

Données fictives utilisées pour illustrer le cycle

4. Première version : tester l'idée avant de construire lourd

Je n'ai pas commencé en développant une application sur mesure.

J'ai commencé avec du no-code.

L'objectif était d'aller vite et de voir si le fonctionnement imaginé avait réellement du sens sur le terrain.

Une première application a donc été construite avec Glide, connectée à un Google Sheet utilisé comme source de données.

D'un côté, les opérations pouvaient renseigner les missions.

De l'autre, l'équipe terrain disposait sur son téléphone d'une interface permettant de retrouver les missions et de suivre leur évolution.

La première version contenait déjà l'essentiel de la logique qui existe aujourd'hui : les missions à réaliser, celles en cours, celles terminées, ainsi que différentes fonctions complémentaires.

Et surtout, elle pouvait être testée avec de vrais utilisateurs.

C'était le principal objectif.

Le prototype fonctionnait.

C'est important, parce que la décision suivante n'est pas venue d'un échec fonctionnel.

Elle est venue des limites du modèle.

Au fur et à mesure que le projet avançait, de nouveaux besoins apparaissaient. Et plus l'application devenait ambitieuse, plus les limites techniques et économiques de la plateforme devenaient importantes.

J'ai augmenté une première fois le niveau d'abonnement.

Puis les besoins ont continué à évoluer.

Et à un moment, la question n'était plus :

« Est-ce que Glide permet de faire ça ? »

mais plutôt :

« Est-ce encore le bon outil pour ce que cette application est en train de devenir ? »

La réponse était non.

Prototype illustratif, les valeurs de l'interface sont fictives

Avec le recul, cette première version n'a pourtant pas été du temps perdu.

Elle a permis de valider le besoin, de tester le fonctionnement et surtout de comprendre beaucoup plus précisément ce que la future application devait faire.

Le prototype no-code avait rempli son rôle.

5. Repartir presque de zéro… mais avec un plan

À ce stade, j'avais quelque chose de beaucoup plus précieux qu'une application Glide.

Je savais ce que je voulais construire.

Les écrans existaient.

Les utilisateurs avaient testé le principe.

Le fonctionnement des missions était défini.

Les besoins commençaient à être connus.

J'ai donc documenté le prototype, récupéré les différents écrans et expliqué précisément le comportement attendu à un assistant de développement.

L'idée était de reconstruire l'application avec davantage de liberté.

C'est à ce moment-là que j'ai commencé à utiliser intensivement Codex comme assistant de développement.

Je ne partais pas avec l'expérience d'un développeur ayant construit des dizaines d'applications.

Il a donc fallu découvrir progressivement tout ce qui existe autour du code lui-même.

Écrire une application est une chose.

La faire tourner correctement en production en est une autre.

Il fallait comprendre comment l'héberger, gérer les paramètres nécessaires à son fonctionnement, connecter les différentes briques, déployer les nouvelles versions et faire communiquer l'application avec les outils existants.

C'est notamment comme cela que Vercel est entré dans l'architecture.

Petit à petit, le prototype no-code est devenu une véritable application web progressive développée sur mesure.

6. Une architecture volontairement pragmatique

L'objectif n'était pas de construire l'architecture la plus impressionnante techniquement.

Il fallait construire quelque chose qui fonctionne dans l'environnement existant.

Le système s'est donc appuyé sur plusieurs briques complémentaires :

Une PWA pour fournir l'expérience utilisateur sur téléphone.

Une couche applicative développée sur mesure pour gérer la logique et les interactions.

Google Sheets pour conserver et exposer certaines données opérationnelles dans un outil que les équipes connaissent déjà.

Apps Script pour automatiser certaines actions autour de ces données.

OneSignal pour apporter les notifications push nécessaires à un véritable usage terrain.

Des services d'hébergement web pour rendre les différentes briques disponibles.

Ce choix est important.

Il aurait été possible d'imaginer une base de données beaucoup plus sophistiquée, un back-office entièrement spécifique et une architecture beaucoup plus lourde.

Mais les opérations travaillaient déjà avec des tableurs.

Pourquoi leur imposer un nouvel outil d'administration si leur outil existant pouvait devenir une partie du système ?

L'architecture devait s'adapter aux utilisateurs.

Pas l'inverse.

7. Transformer un Google Sheet en moteur opérationnel

Une des choses que j'aime le plus dans ce projet est le décalage entre ce que voit l'utilisateur et ce qui se passe réellement derrière.

Sur son téléphone, l'utilisateur voit une application.

Il ouvre une mission.

Il appuie sur un bouton.

Par exemple :

« Je prends cette mission. »

Pour lui, c'est tout.

Mais cette action modifie une information dans le système central.

Cette nouvelle information peut ensuite déclencher différentes logiques : mise à jour du responsable, changement de statut, déplacement de la mission dans la bonne vue, notification des autres systèmes ou préparation de son archivage.

Même principe lorsqu'une mission est terminée.

Une information de livraison est renseignée.

Une automatisation peut alors détecter que les conditions attendues sont réunies et mettre à jour automatiquement l'état de la mission.

L'application reflète ensuite ce nouvel état pour présenter à chaque utilisateur les informations pertinentes.

Il n'y a rien de magique derrière.

C'est justement ce que je trouve intéressant.

Une succession de mécanismes relativement simples peut produire une expérience très fluide lorsque le processus a été correctement pensé.

8. Une application utile devait faire plus que déplacer des lignes

Une fois le fonctionnement principal stabilisé, de nouveaux besoins sont naturellement apparus.

Savoir qui fait quoi

Chaque mission peut être associée à la personne qui l'a prise en charge.

Depuis l'application, les équipes peuvent donc voir les missions qui leur sont attribuées, mais également disposer d'une vue plus globale de l'activité en cours.

Les opérations disposent elles aussi de cette visibilité.

Suivre l'avancement

Une mission n'est plus simplement « dans la boîte mail » ou « répondue ».

Elle possède un état identifiable.

Cela rend le processus beaucoup plus lisible.

Conserver des preuves

Des photos peuvent être ajoutées directement à une mission.

Des signatures peuvent également être conservées.

Cela permet de rattacher la preuve à la mission concernée au lieu de devoir la rechercher plus tard dans différents échanges.

Les opérations peuvent elles aussi retrouver ces éléments depuis leur environnement.

Illustration conceptuelle, interfaces, données et exemples entièrement fictifs

9. Les notifications : le détail qui change l'usage

Une application terrain peut être parfaitement conçue et malgré tout échouer pour une raison très simple :

personne ne passe sa journée à la rafraîchir pour voir si une nouvelle mission est arrivée.

Avec une boîte mail, ce problème était partiellement résolu par les notifications du téléphone.

En remplaçant l'email, il fallait donc recréer ce mécanisme.

C'est ce besoin qui m'a amené à travailler sur les notifications Web Push, notamment avec OneSignal et une brique web dédiée à leur activation.

Lorsqu'une nouvelle mission nécessite l'attention d'un utilisateur, celui-ci peut désormais être prévenu comme il le serait avec une application classique.

Cette partie paraît secondaire dans l'architecture générale.

Sur le terrain, elle ne l'est absolument pas.

Elle transforme un outil qu'il faut penser à consulter en un outil capable de venir chercher l'utilisateur lorsque c'est nécessaire.

10. Et les opérations dans tout ça ?

Il ne fallait surtout pas améliorer la vie d'un côté en déplaçant la charge de travail de l'autre.

L'équipe opérationnelle devait elle aussi gagner en visibilité.

Une autre couche d'automatisation a donc été ajoutée autour des actions importantes réalisées sur le terrain.

Lorsqu'un utilisateur prend en charge une mission ou réalise certaines étapes, le système peut générer automatiquement une information à destination des personnes concernées.

Dans certains cas, cela prend la forme d'un email préformaté.

L'utilisateur terrain ne doit donc pas nécessairement quitter l'application pour informer manuellement les autres acteurs de chaque changement important.

Une partie de cette communication peut être produite directement à partir de l'action réalisée dans l'application.

Encore une fois, le gain vient moins d'une technologie spectaculaire que de la suppression de petites actions répétées des dizaines ou centaines de fois.

11. Le vrai développement commence quand les utilisateurs arrivent

Je pourrais raconter qu'après plusieurs semaines de développement, l'application était terminée et que tout fonctionnait parfaitement.

Ce serait faux.

En réalité, il n'y a pas eu un énorme bug qui aurait soudainement remis tout le projet en question.

Il y a eu quelque chose de beaucoup plus classique : des dizaines de petites améliorations.

Une photo met trop longtemps à charger.

Une automatisation ne se déclenche pas exactement comme prévu.

Un utilisateur utilise une fonctionnalité d'une manière que je n'avais pas anticipée.

Une modification du tableur risque d'avoir des conséquences sur l'application.

Une information qui paraissait évidente lors de la conception ne l'est finalement pas suffisamment sur le terrain.

Puis on corrige.

On teste.

On redéploie.

Et on recommence.

C'est probablement une des principales différences entre construire une démonstration et construire un outil métier.

Une démonstration doit fonctionner pendant quelques minutes.

Un outil métier doit continuer à fonctionner lorsque de vraies personnes l'utilisent tous les jours.

12. Les limites font aussi partie du projet

L'architecture actuelle n'est pas parfaite.

Et je trouve important de le dire.

L'utilisation d'un tableur comme élément central apporte énormément de simplicité et permet aux opérations de garder un environnement familier.

Mais cela crée aussi une certaine fragilité.

Une modification mal maîtrisée de la structure peut avoir des conséquences sur les automatisations ou sur l'application.

Certaines opérations liées aux médias peuvent également être améliorées.

Et plus le volume, le nombre d'utilisateurs ou les fonctionnalités augmenteront, plus la question d'une évolution de certaines briques se posera.

Mais une architecture ne doit pas être évaluée uniquement sur sa sophistication technique.

Elle doit être évaluée par rapport au problème qu'elle doit résoudre au moment où elle doit le résoudre.

Le système actuel a permis de passer rapidement d'un processus largement basé sur les emails à une application opérationnelle réellement utilisée, sans reconstruire tout le système d'information autour.

C'était la priorité.

13. Ce qui a réellement changé

La différence la plus importante n'est pas esthétique.

Avant, une grande partie de l'information vivait dans les échanges entre personnes.

Après, elle vit dans le processus.

Avant, il fallait chercher qui avait pris une mission.

Maintenant, le système le sait.

Avant, il fallait suivre les réponses pour comprendre son avancement.

Maintenant, elle possède un statut.

Avant, une preuve pouvait être dispersée dans différents échanges.

Maintenant, elle peut être rattachée à la mission.

Avant, certaines communications nécessitaient une nouvelle action humaine.

Maintenant, elles peuvent être déclenchées automatiquement.

Et surtout, le problème initial pouvait naturellement conduire à ajouter toujours plus de coordination humaine à mesure que l'activité augmentait.

Une autre voie a été choisie :

construire le système qui permet aux équipes de mieux se coordonner elles-mêmes.

Illustration conceptuelle, interfaces, données et exemples entièrement fictifs

14. Ce que je retiens de ce projet

Quand j'ai commencé ce projet, je ne suis pas parti avec l'idée de développer une PWA, d'utiliser Vercel, de mettre en place des notifications Web Push ou d'écrire des automatisations Apps Script.

Je voulais résoudre un problème beaucoup plus simple :

Comment éviter que plusieurs personnes passent leur temps à surveiller une boîte mail et à se coordonner manuellement autour d'elle ?

La première réponse a été le no-code.

Elle a permis de tester l'idée rapidement.

Lorsque cette solution a atteint ses limites, le besoin était suffisamment clair pour passer au développement sur mesure.

Puis les besoins terrain ont amené les notifications.

Les automatisations ont amené d'autres automatisations.

Les retours utilisateurs ont amené de nouvelles versions.

Et l'application actuelle est finalement le résultat de toutes ces étapes.

C'est probablement ce que je retiens le plus de ce projet :

je ne crois pas qu'il faille commencer un projet d'automatisation en choisissant une technologie.

Il faut commencer par regarder le processus.

Comprendre ce que font réellement les personnes.

Identifier ce qui leur fait perdre du temps.

Puis construire la solution la plus simple capable de supprimer cette friction.

Parfois, ce sera une formule Excel.

Parfois, un Power Automate.

Parfois, quelques lignes de script.

Et parfois, cela finira par devenir une application métier complète.

Vous avez un processus qui ressemble encore à ça ?

Une boîte mail partagée, des fichiers Excel, des copier-coller, des relances, des informations dispersées ou une personne qui passe une partie de sa journée à faire circuler les mêmes données ?

Ce n'est pas forcément un problème d'outil.

C'est souvent un problème de processus qui n'a jamais été repensé depuis que les outils se sont accumulés autour de lui.

C'est précisément le type de sujet sur lequel j'aime travailler : comprendre le fonctionnement actuel, identifier ce qui peut disparaître et construire un système adapté au besoin réel.