Remplacer le tableur par un logiciel : quand le back-office s'impose

L'essentiel en bref

Un back-office sur mesure est un petit système web, conçu pour un processus propre à l'entreprise, avec une base de données, une connexion par personne et des règles que le système applique tout seul ; il se justifie quand un tableur partagé en est venu à avoir plusieurs personnes qui modifient la même donnée et que l'erreur coûte de l'argent. Le tableur ne cède pas parce qu'il est gros. Il cède sur quatre points : l'édition simultanée, un historique qui n'explique rien, des droits qui ne distinguent pas les personnes et des règles métier que personne ne vérifie à la saisie. La page consacrée aux systèmes sur mesure montre où ce back-office se situe par rapport à d'autres projets. Le seuil pour changer n'est ni le chiffre d'affaires ni le nombre de salariés : c'est le nombre de personnes qui écrivent dans le même tableur et ce que coûte une valeur erronée qui passe à l'étape suivante. Voici comment reconnaître chaque point de rupture, le critère de bascule et ce qu'il faut rassembler avant de demander un back-office.

Quel logiciel remplace Excel ?

Il n'existe pas un programme unique qui remplace Excel dans n'importe quelle entreprise. Pour un processus opérationnel, le remplaçant est généralement un back-office sur mesure ou un outil prêt à l'emploi doté d'une base de données, d'utilisateurs et de droits. Le choix dépend de la règle qui doit être appliquée, des systèmes déjà en place et du besoin que chaque personne ne voie que les données correspondant à son rôle.

Excel reste utile comme tableur d'analyse, d'import et d'export. Il cesse d'être une bonne source officielle quand le même enregistrement passe par les ventes, le stock, la comptabilité et l'expédition, parce que la cellule ne représente pas l'opération entière. À ce stade, le système doit conserver la donnée centrale, bloquer les combinaisons non valides et enregistrer qui a fait chaque modification.

1. Les quatre points où le tableur partagé cède

Le tableur est un excellent outil pour qu'une personne réfléchisse. Les problèmes commencent quand il devient le système d'un processus entier, avec des gens de services différents qui y écrivent toute la journée. Google Sheets et Excel ont une fonction pour chacun des problèmes ci-dessous. Ce qui manque, ce n'est pas la fonction : c'est que la fonction soit obligatoire et ne dépende pas de la bonne volonté de celui qui modifie.

Chaque ligne de ce tableau fait l'objet d'une section. La question est toujours la même : quand la règle échoue, qui s'en aperçoit, et quand.

2. Édition simultanée : le problème n'est pas le fichier, c'est l'opération

La co-édition a réglé le vieux problème du « fichier verrouillé en modification ». Aujourd'hui, plusieurs personnes ouvrent le même tableur et saisissent en même temps. Dans Excel, la documentation de Microsoft conditionne cela à l'enregistrement du fichier sur OneDrive ou SharePoint Online et à l'utilisation de versions compatibles avec la co-édition. Dans Sheets, c'est le comportement par défaut.

Ce que la co-édition ne règle pas, c'est qu'un processus métier se résume rarement à une cellule. « Préparer la commande » touche au statut, à la quantité réservée, à la date d'expédition et parfois au solde de stock d'un autre onglet. Le tableur synchronise chaque cellule isolément. Il ne sait pas que ces quatre cellules forment une seule opération.

Comment cela se manifeste au quotidien

• Deux personnes réservent la dernière unité du même article, chacune sur une ligne, parce que le solde ne se met à jour qu'une fois la formule recalculée.
• Quelqu'un trie tout l'onglet pendant qu'une autre personne saisit, et la valeur saisie atterrit sur la mauvaise ligne.
• Un filtre appliqué par une personne masque des lignes qu'une autre est en train de vérifier, et la vérification se termine « sans anomalie ».
• Une formule étirée jusqu'au bas de la colonne est effacée par quelqu'un qui colle des données par-dessus.

Aucun de ces cas n'est la négligence d'une personne en particulier. C'est le résultat prévisible de plusieurs personnes qui écrivent dans une structure dépourvue de notion de transaction.

Ce qu'une base de données fait différemment

Dans un back-office adossé à une base relationnelle, « préparer la commande » est une transaction : soit toutes les modifications passent, soit aucune. Si deux personnes tentent de réserver la dernière unité, la base sérialise les deux tentatives et la seconde reçoit une erreur claire au lieu d'un solde négatif silencieux. Trier et filtrer deviennent des réglages de l'écran de chacun, sans modifier les données des autres.

3. Historique : savoir que ça a changé n'est pas savoir pourquoi

L'historique des versions de Google Sheets affiche les versions antérieures, qui a modifié, et permet de restaurer. C'est une bonne fonction pour réparer un dégât. Pour piloter un processus, elle a deux limites.

La première, c'est la granularité. Restaurer une version annule tout ce qui s'est passé après, y compris le travail correct des autres. En pratique, personne ne restaure : quelqu'un compare les versions à la main et corrige cellule par cellule.

La seconde, c'est le contexte. L'historique enregistre que la cellule est passée de « en attente » à « payé ». Il n'enregistre pas au titre de quelle commande, sur la base de quel justificatif, ni si la personne qui a modifié avait la fonction requise pour valider un paiement. Quand la question est « qui a autorisé ça ? », le tableur répond seulement « qui l'a saisi ».

Ce qui compte comme historique utile

Un historique utile répond à quatre questions sans que personne ait besoin d'ouvrir d'anciennes versions : ce qui a changé, de quelle valeur à quelle valeur, qui l'a changé et par quelle action du système. Cela prend la forme d'une table d'audit dans la base. La documentation de PL/pgSQL, de PostgreSQL, donne elle-même un exemple de fonction de trigger qui enregistre dans une table séparée chaque insertion, modification et suppression, avec l'utilisateur et l'horodatage.

CREATE TRIGGER auditar_pedidos
AFTER INSERT OR UPDATE OR DELETE ON pedidos
FOR EACH ROW EXECUTE FUNCTION registrar_auditoria();

La différence avec l'historique du tableur : l'enregistrement naît en même temps que la modification, par la même porte, et modifier une donnée via le système laisse une trace par définition.

4. Droits par personne : protéger une cellule n'est pas contrôler l'accès

Dans Google Sheets, on peut protéger une feuille ou une plage et choisir qui peut la modifier, ou simplement afficher un avertissement à qui s'y essaie. Dans Excel, il existe la protection de feuille par mot de passe. Les deux servent à éviter que quelqu'un efface une formule par mégarde. Aucune des deux n'a été conçue pour séparer ce que chaque personne peut voir.

Microsoft est direct dans sa documentation : la protection de feuille d'Excel n'est pas une fonction de sécurité. Elle empêche de modifier les cellules verrouillées, et c'est tout. Dans Sheets, la protection contrôle la modification ; quiconque a accès au fichier continue de voir le contenu des onglets.

Là où cela devient un problème

• Le commercial doit voir ses propres commandes, mais le tableur est unique et affiche la commission de tout le monde.
• La comptabilité doit valider les paiements, mais le même tableur laisse le service stock modifier le champ « payé ».
• Un prestataire externe doit mettre à jour le statut de livraison et, pour cela, reçoit l'accès au fichier entier, avec les données clients.

Le troisième cas a une portée juridique. La LGPD, loi brésilienne sur la protection des données, exige à l'art. 46 des mesures techniques et administratives pour protéger les données personnelles contre les accès non autorisés. Partager tout le tableur pour que quelqu'un modifie une colonne est difficile à défendre comme mesure adéquate.

Comment le back-office règle la question

Dans le back-office, les droits se définissent par rôle et, si nécessaire, par ligne. Le commercial voit ses commandes ; la comptabilité voit le champ de paiement et rien d'autre ; le prestataire ne voit que les livraisons qui lui sont attribuées. PostgreSQL le fait directement dans la base avec Row Level Security, et la documentation décrit le comportement par défaut lorsqu'aucune politique n'est définie : « a default-deny policy ». Autrement dit, la base refuse par défaut et ouvre ce qui a été explicitement autorisé. C'est l'inverse du tableur, qui ouvre tout et essaie de protéger des morceaux.

5. Règle métier à la saisie : la validation qui se contente d'avertir

La validation des données de Sheets propose deux options lorsque la donnée n'est pas valide : afficher un avertissement ou refuser la saisie. Beaucoup de tableurs opérationnels sont réglés sur l'avertissement, parce qu'à un moment quelqu'un a eu besoin de « juste faire passer ce cas » et le refus a gêné. À partir de là, la règle devient une suggestion.

Même réglée pour refuser, la validation s'applique à la cellule. Elle vérifie que la date est une date, que la valeur figure dans une liste. Elle ne sait pas que la date de livraison ne peut pas précéder la date de commande, qu'une remise au-delà d'un certain plafond exige une approbation, ou qu'une commande annulée ne peut pas recevoir de validation de paiement. Ces règles vivent dans la tête de ceux qui opèrent et, avec un peu de chance, dans un document que personne n'ouvre.

La règle au bon endroit

Dans un back-office, la règle métier se trouve à deux endroits. À l'écran, pour guider la saisie. Dans la base, pour refuser ce qui a contourné l'écran par n'importe quel chemin : import, intégration, correction manuelle. La documentation de PostgreSQL est explicite : lors d'une tentative d'écrire une valeur qui viole une contrainte, « an error is raised ».

ALTER TABLE pedidos
  ADD CONSTRAINT entrega_depois_do_pedido
  CHECK (data_entrega >= data_pedido);

Ainsi, la règle ne dépend plus de la mémoire de quelqu'un. La donnée erronée n'entre pas, et le message d'erreur dit pourquoi.

6. Le seuil : combien de personnes modifient et combien coûte l'erreur

Le critère qui revient le plus souvent dans les conversations, c'est la taille : « quand l'entreprise aura grandi, on fera un système ». La taille est un mauvais indicateur. Une grande entreprise peut avoir un tableur que seul le contrôleur de gestion modifie, et il fonctionne. Une petite entreprise peut avoir un tableur de commandes modifié par les ventes, le stock, l'expédition et la comptabilité, et il est déjà le goulot d'étranglement.

Deux variables tranchent mieux :

1. Combien de personnes écrivent dans la même donnée. Une personne qui modifie et plusieurs qui lisent, c'est un usage sain du tableur. Plusieurs personnes qui écrivent dans les mêmes lignes, c'est là que les quatre points de rupture apparaissent ensemble.
2. Combien coûte une valeur erronée qui passe à l'étape suivante. Une erreur que quelqu'un repère vite et corrige sur le moment coûte peu. Une erreur qui se transforme en commande mal facturée, en stock faux, en paiement validé deux fois ou en données clients exposées coûte cher, et se découvre généralement tard.

La dernière ligne du tableau est celle où le back-office se rentabilise. Non pas grâce à un gain de productivité que quelqu'un pourrait promettre en chiffres, mais parce que chaque erreur évitée à cet endroit a un coût direct et mesurable par l'entreprise elle-même : facture annulée, livraison refaite, client remboursé, heures de vérification.

7 signes que le tableur est bloqué

1. Il existe une personne dont la fonction officieuse est de « remettre le tableur en ordre ».
2. Il y a des copies du tableur par service, et la réunion sert à réconcilier les copies.
3. Quelqu'un a déjà demandé « qui a changé ça ? » et la réponse a consisté à comparer les anciennes versions.
4. Le tableur a un onglet nommé « ne pas toucher ».
5. Une formule ou un filtre modifié change le résultat pour tout le monde.
6. La même commande doit être saisie dans plus d'un fichier.
7. Personne n'est capable d'expliquer quelle version est la source officielle de la donnée.

Logiciel interne pour l'entreprise : ce que contient un back-office

On confond parfois « back-office » avec un tableau de bord de graphiques. Ici, le sens est autre : c'est l'outil dans lequel l'activité se déroule, les graphiques n'en étant qu'une conséquence. Un back-office sur mesure bien conçu comporte au minimum :

• Une base de données relationnelle avec les règles métier sous forme de contraintes, pour que la base refuse la donnée non valide, qu'elle vienne de l'écran, d'un import ou d'une intégration.
• Une connexion individuelle et des rôles (ventes, stock, comptabilité, externe), avec des droits par écran, par champ et, si nécessaire, par ligne.
• Une piste d'audit automatique : ce qui a changé, de quelle valeur à quelle valeur, qui et quand.
• Des écrans par tâche, pas par table : « préparer la commande », « valider le paiement », « enregistrer un retour », chacun ne touchant qu'à ce que la tâche exige.
• Import et export vers un tableur, parce que le tableur reste excellent pour l'analyse ponctuelle. La différence, c'est qu'il devient une sortie, et non plus la source.

Le coût et le délai dépendent du périmètre, notamment de l'intégration avec d'autres systèmes, de la granularité des droits et de l'audit. Si le back-office alimente aussi un front public, l'article sur WordPress headless aide à séparer l'exploitation et la présentation.

Combien coûte le passage du tableur à un logiciel ?

Il n'y a pas de prix sérieux sans connaître le processus. L'intégration, les droits, l'audit et la migration des données font davantage varier le périmètre que le nombre d'écrans. L'article Combien coûte le développement d'un système web sur mesure explique comment comparer une proposition et le coût d'exploitation, sans transformer une estimation en promesse.

8. Comment cartographier le processus avant de demander le back-office

L'élément le plus utile pour un devis honnête, c'est le tableur actuel accompagné de la description du processus qui l'entoure. Avant d'échanger avec la personne qui va développer, il vaut la peine de noter :

• Qui modifie quoi. La liste des personnes ou des fonctions et les colonnes que chacune modifie au quotidien.
• Les règles qui vivent aujourd'hui dans les têtes. « Une remise au-delà de tant exige une approbation », « une commande annulée ne peut pas être validée en paiement », « seule la comptabilité marque comme payé ».
• Les erreurs déjà survenues. Quelques cas concrets, avec ce que chacun a coûté. Ils montrent où la règle doit se trouver dans la base.
• Avec quoi le tableur communique. ERP, boutique en ligne, banque, e-mail, autre tableur. Chaque intégration fait partie du périmètre.
• Qui doit voir sans modifier. Direction, expert-comptable, prestataire externe.

Avec ces éléments en main, on peut distinguer ce qui est essentiel dans la première version de ce qui peut attendre. Un back-office n'a pas besoin de couvrir tout le processus dès sa naissance : commencer par la partie où plusieurs personnes écrivent et où l'erreur coûte cher suffit déjà à sortir le tableur du chemin critique.

Questions fréquentes

On ne peut pas régler ça avec Apps Script ou une macro dans le tableur lui-même ?

On peut automatiser des tâches et renforcer certaines règles. La limite reste la même : quiconque a le droit de modifier le fichier peut contourner la règle en modifiant directement la cellule, et le tableur reste sans transaction et sans droits par ligne. Le script est un bon palliatif quand le problème est la répétition ; il ne règle rien quand le problème, c'est plusieurs personnes qui écrivent dans la même donnée avec une erreur coûteuse.

Un outil no-code ne règle-t-il pas le même problème ?

Dans bien des cas, oui, et il vaut la peine de l'envisager avant un back-office sur mesure. Les outils no-code adossés à une base de données offrent déjà une connexion par personne et un certain contrôle des droits. Le seuil apparaît généralement quand la règle métier est trop spécifique pour l'outil, quand les droits doivent descendre au niveau de la ligne ou quand il faut une intégration avec un ERP ou une boutique que l'outil ne couvre pas.

L'équipe va-t-elle perdre la souplesse du tableur ?

Elle perd la souplesse de modifier le processus sans que personne le sache, et c'est précisément ce qui génère l'erreur. La souplesse d'analyse demeure : le back-office exporte vers un tableur, et chacun peut construire le tableau croisé dynamique de son choix à partir d'une donnée désormais fiable.

Le back-office remplace-t-il l'ERP ?

Ce n'est pas l'objectif. Le back-office couvre le processus que l'ERP ne couvre pas ou couvre mal, et qui a donc fini dans le tableur. Quand il y a un ERP, le back-office lit et écrit dedans par intégration, au lieu de dupliquer les fiches.

Conclusion

Le tableur partagé devient un goulot d'étranglement quand plusieurs personnes écrivent dans la même donnée et que l'erreur coûte cher, pas quand l'entreprise grandit. Les symptômes se répètent : une édition qui écrase, un historique qui n'explique pas, des droits qui ne séparent pas et une règle qui se contente d'avertir. Un back-office sur mesure règle les quatre en plaçant les règles dans la base, et non dans la mémoire de ceux qui opèrent. Si c'est votre cas, envoyez via oailton.dev/fr/contato le processus qui tourne aujourd'hui sur le tableur et le nombre de personnes qui le modifient, et je vous dirai s'il s'agit d'un cas de back-office, d'un ajustement du tableur lui-même ou d'un outil prêt à l'emploi.

Pour voir comment je mène les projets de système sur mesure, de la découverte à la maintenance, la page Systèmes résume le service et le portfolio montre des cas livrés.