Olya est un ERP mobile que je développe seul : le produit, l'application, l'API, la base de données, les arbitrages. Le projet n'est pas parti d'une envie de tester une technologie, mais d'un constat assez banal chez les entreprises que j'accompagne. Les outils de gestion ne manquent pas. C'est la cohérence entre eux qui manque. Voici pourquoi j'ai lancé Olya, ce qu'elle cherche à résoudre, et comment elle est construite.
Pourquoi un ERP mobile
Dans une PME, le stock vit dans un tableur, les clients dans un CRM gratuit, le planning dans un agenda partagé, les devis dans un dossier Drive et les décisions dans une conversation WhatsApp. Chaque outil fait très bien son travail. Le problème apparaît entre eux. La même information est saisie deux fois, modifiée d'un côté, oubliée de l'autre, et plus personne ne sait quelle version fait foi. Les équipes passent une partie de leur journée à recopier, le dirigeant n'a pas de vue d'ensemble, et la question qui revient le plus souvent en réunion devient « on a ça où, déjà ? ». Olya part de là. Pas d'un manque de fonctionnalités, d'un manque de continuité.
Ce que fait Olya aujourd'hui
L'application regroupe les fonctions dont une entreprise se sert tous les jours. L'inventaire suit le matériel et les consommables. Le planning organise les journées, les tâches et les événements. La gestion d'équipe rassemble les membres de l'entreprise et leurs rôles. Le CRM centralise les clients et les fournisseurs. La partie facturation prépare la gestion commerciale. Les notes gardent au même endroit ce qui finit d'habitude dans un carnet ou dans un fil de messages. Et la fiche entreprise tient les informations de l'organisation et des utilisateurs. Pris un par un, ces modules existent déjà ailleurs. Ce qui change ici, c'est qu'ils partagent la même base, le même compte et les mêmes droits.
Pourquoi le mobile d'abord
La plupart des gestes de gestion ne se font pas assis à un bureau. Vérifier qu'il reste des pièces avant de partir sur un chantier, retrouver le numéro d'un client depuis une camionnette, décaler une intervention parce qu'un rendez-vous a duré, noter une remarque juste après la visite. Les ERP classiques sont pensés pour un grand écran et une souris, donc ces gestes attendent le retour au bureau, quand ils ne sont pas oubliés en route. Olya est conçue dans l'autre sens. L'écran d'accueil montre ce qui concerne la journée en cours, et une action utile doit tenir en deux ou trois touches. Cette contrainte a un effet direct sur le produit : chaque écran oblige à trancher entre ce qui est vraiment nécessaire sur téléphone et ce qui peut attendre une version web.
React Native et Expo
L'application est écrite en React Native avec Expo. React Native me permet de garder mes réflexes React tout en produisant une vraie application mobile, pas un site emballé dans une coque. Expo enlève une bonne partie de la friction : environnement de développement, accès aux fonctionnalités natives, compilation, mises à jour. Quand on est seul sur un projet, c'est du temps qui ne part pas dans la configuration Xcode et Gradle, donc du temps qui va dans les fonctionnalités. Le compromis existe et il faut le connaître : dès qu'une brique native sort du cadre prévu, il faut passer par un build de développement et remettre les mains dans la configuration. Sur ce projet, l'échange reste largement gagnant.
Node, Express et une seule source de vérité
Le serveur tourne sous Node avec Express. Il expose l'API que consomme l'application et il porte les règles de gestion. Ce point compte encore plus dans un ERP qu'ailleurs. Une quantité en stock, un droit d'accès, un statut de facture : ce sont des règles qui doivent donner le même résultat quel que soit l'endroit d'où l'utilisateur agit. Si l'application mobile décide toute seule qu'un mouvement de stock est valide, la règle existe en deux exemplaires, et le jour où j'ajoute un back-office web, elle en existera trois. L'application ne décide donc de rien. Elle affiche, elle envoie, elle réagit à la réponse.
MongoDB et les modèles métier
Les données sont dans MongoDB, avec des modèles qui suivent le métier : Company, User, Inventory, Invitations, CrmClient. Le choix du document se justifie par la nature du projet. Les entreprises ne fonctionnent pas toutes de la même manière, les besoins bougent, et un module encore jeune gagne un champ toutes les deux semaines. Pouvoir ajouter une information sans migration lourde change le rythme quand on développe seul. La contrepartie demande de la discipline : un schéma Mongoose explicite pour chaque modèle, des index posés dès qu'une collection est destinée à grossir, et jamais un document qui traîne sans propriétaire clairement identifié.
Le multi-entreprise, la vraie difficulté
C'est le point qui structure tout le reste. Chaque document appartient à une entreprise, et chaque requête doit être filtrée par cette entreprise, sans exception. Un oubli sur une seule route et un client voit l'inventaire d'un autre. La règle que je m'impose est simple : ce n'est jamais l'application qui envoie l'identifiant de l'entreprise, il est déduit du jeton de l'utilisateur côté serveur. Les rôles se vérifient au même endroit, dans la couche métier, et pas seulement dans l'écran qui cache un bouton. Les invitations suivent la même logique. On rejoint une organisation par un lien à usage unique et à durée limitée, qui crée l'appartenance et le rôle en une seule opération, ce qui évite les comptes à moitié rattachés dont personne ne sait quoi faire six mois plus tard.
Une architecture faite pour accueillir des modules
Le découpage est classique, et c'est exactement ce que je cherchais : interface mobile, API, logique métier, base de données. Chaque couche ne connaît que la suivante. Ajouter un module revient donc à écrire un modèle, un service qui porte ses règles, quelques routes et les écrans correspondants, sans toucher au reste. C'est ce qui permet à un projet solo de continuer d'avancer au bout de six mois. Une base astucieuse mais emmêlée coûte peu au début, puis fait payer chaque nouvelle fonctionnalité au prix fort, jusqu'au moment où on préfère réécrire plutôt que rouvrir le dossier.
La navigation quand les écrans se multiplient
Un ERP, ce sont beaucoup d'écrans, et sur mobile c'est le premier endroit où tout peut partir en vrille. Chaque module a sa propre pile de navigation : on retrouve un module là où on l'avait laissé, et le retour arrière fait toujours la même chose. Ça paraît anecdotique tant qu'on n'a que quatre écrans. C'est pourtant ce qui donne l'impression d'un outil de travail plutôt que d'un enchaînement de pages. J'y ajoute une règle personnelle : aucune information importante ne doit se trouver à plus de deux niveaux de profondeur depuis l'accueil.
Les sujets natifs qu'on sous-estime
Générer un PDF puis le partager, gérer les dates et les fuseaux sans décaler une intervention d'une journée, demander les bonnes permissions au bon moment, garder une compatibilité correcte sur des Android qui ne sont pas neufs. Ces sujets n'apparaissent sur aucune capture d'écran, mais ce sont eux qui décident si l'application est réellement utilisable sur le terrain. J'ai passé plus de temps sur la génération et le partage de documents que sur certains modules entiers, et c'était le bon arbitrage : un devis qu'on ne peut pas envoyer depuis le téléphone ramène l'utilisateur devant son ordinateur, donc au point de départ.
Les erreurs qui ont fait progresser le code
Les problèmes les plus formateurs sont venus de l'état. Des données encore affichées à l'écran alors qu'elles étaient périmées en base, des rafraîchissements qui ne partaient pas au bon moment, des écrans remontés pour rien. La correction n'a pas été un rustine posée sur un écran, mais un changement de méthode. L'état serveur est passé dans un cache de requêtes, avec des clés explicites et une invalidation après chaque écriture. L'état purement local est resté local. Depuis, cette catégorie de bug ne revient plus, ce qui est la seule preuve valable qu'un problème a été traité à la racine et pas seulement masqué.
Développer seul : la contrainte devient un filtre
En solo, on tient le produit, l'application, l'API, la base, les tests et la mise en ligne. Il n'y a pas d'équipe pour absorber une mauvaise décision. Alors avant chaque fonctionnalité, trois questions. Est-ce qu'elle sert vraiment à quelqu'un ? Est-ce qu'elle doit exister maintenant ? Est-ce que l'architecture actuelle la supportera dans six mois ? Beaucoup d'idées ne passent pas ce filtre, et c'est très bien ainsi. Ce que ça m'a appris vaut pour n'importe quel projet, en équipe ou pas : cinq modules cohérents valent mieux que douze modules à moitié finis.
La valeur d'un ERP tient dans les liens
Un ERP qui aligne des modules indépendants ne sert à rien. Ce sont des applications séparées rangées dans le même menu. L'intérêt commence quand une intervention du planning consomme du matériel de l'inventaire, qu'elle est rattachée à un client du CRM, réalisée par un membre de l'équipe, et qu'elle peut devenir une ligne de facture. À ce moment-là, l'information n'est plus saisie trois fois, et le dirigeant peut répondre à la seule question qui compte vraiment : où en est l'activité. C'est la direction que suit le produit, module après module, et c'est ce qui distingue un ERP d'un tiroir bien rangé.
La suite
Le socle actuel ouvre plus de portes qu'il n'en ferme : automatisation des tâches répétitives, gestion commerciale plus complète, tableaux de bord, intégrations avec les outils déjà en place, fonctions d'intelligence artificielle pour la saisie et la recherche, gestion de projet, et surtout des workflows entre les modules. La règle que je me fixe est de n'ajouter de la puissance qu'à condition de ne pas ajouter de complexité visible. Un ERP devient inutilisable le jour où il faut deux jours de formation pour enregistrer un client.
Ce que ce projet m'a appris
Beaucoup plus que du code. Trancher entre deux fonctionnalités quand on n'a le temps que pour une. Écrire une base qu'on pourra rouvrir dans six mois sans la relire en entier. Accepter de sortir une version imparfaite pour la confronter à un usage réel plutôt que de la peaufiner dans le vide. Et voir de très près la différence entre un logiciel qui fait beaucoup de choses et un logiciel dans lequel les choses fonctionnent ensemble.
Ce que je vise avec Olya
Olya part d'une idée simple : rendre la gestion d'entreprise plus centralisée, plus mobile et plus accessible. Le projet avance module après module, avec React Native et Expo côté application, Node, Express et MongoDB côté serveur, et une architecture qui laisse de la place à la suite. Ce n'est pas seulement une application que je développe. C'est une façon de voir ce que devrait être un ERP quand il est pensé pour la personne qui s'en sert debout, entre deux rendez-vous, et pas pour celle qui remplit un tableau au fond d'un bureau.