À quel moment exactement un tableur cesse-t-il de suffire ?

Information générale, à jour au 26 juillet 2026 et fondée sur les textes cités en fin d'article. Elle ne constitue ni un conseil fiscal, ni un conseil juridique : la réglementation évolue et son application dépend de votre situation. Validez toujours avec votre expert-comptable ou votre conseil.

Quatre processus font céder un tableur avant tous les autres : les achats, le stock, le temps passé sur les projets et le service client. Ils cassent au même endroit — plusieurs personnes écrivent dans la même donnée, et plus personne ne sait laquelle fait foi. Pour chacun, cette page donne le symptôme qui déclenche le besoin, la procédure cible, et le module qui la porte.

Pourquoi un tableur cède-t-il sur ces quatre processus ?

Parce qu'un tableur n'a ni règle d'écriture, ni trace, ni état partagé : une cellule se corrige sans que personne le sache, et deux copies du même fichier divergent en une journée. Dans un article de synthèse déposé sur arXiv le 2 février 2016 et consulté le 26 juillet 2026, Ray Panko, professeur à l'université de Hawaï, écrit que « spreadsheet errors are rare on a per-cell basis, but in large programs, at least one incorrect bottom-line value is very likely to be present » — les erreurs sont rares rapportées à la cellule, mais un grand tableur porte très probablement au moins un total faux. Le même texte les dit « extremely difficult to detect and correct ».[1]

Le point de bascule n'est donc ni un effectif, ni un chiffre d'affaires : c'est le nombre de mains sur la même donnée. Dès qu'un acheteur engage une dépense, qu'un magasinier réceptionne et qu'un comptable paie, il faut une règle qui dise qui écrit quoi, et une trace qui dise qui a écrit.

Achats : à partir de quel montant une commande doit-elle être approuvée ?

Le symptôme est une facture fournisseur qu'aucun bon de commande n'annonçait. Suivent la commande passée par téléphone, la livraison partielle que personne n'a rapprochée, et le prix facturé qui ne correspond plus à celui qui avait été négocié. Cause commune : l'engagement de dépense et sa réception ne sont écrits nulle part avant l'arrivée de la facture.

La procédure cible tient en quatre temps. La demande prend la forme d'une commande à l'état brouillon ; au-delà d'un seuil paramétré par société, 10 000 dirhams par défaut au 26 juillet 2026, elle passe par « Soumettre pour approbation » puis « Approuver et envoyer ». Le numéro de bon de commande n'est alloué par la base de données qu'à la sortie du brouillon. La réception se saisit à l'arrivée de la marchandise, totale ou partielle, et génère elle-même les mouvements de stock.

Le rapprochement à trois voies confronte enfin la facture, la commande et les réceptions : au 26 juillet 2026, les écarts de prix sont tolérés à 2 %, les écarts de quantité signalés à l'unité près, et les lignes facturées hors commande isolées. Le module Achats & Fournisseurs porte cette chaîne jusqu'au paiement par lot. Le seuil et la tolérance restent vos décisions : aucun logiciel ne dira quel écart est acceptable.

Stock : pourquoi un tableur ne donne-t-il jamais la quantité réellement disponible ?

Parce qu'il additionne des entrées et des sorties passées, quand la question porte sur ce qui est encore vendable. Trois incidents signalent la bascule : vendre une quantité déjà réservée par une commande en cours, découvrir la rupture au moment de préparer la livraison, constater l'écart au seul inventaire annuel.

La procédure cible sépare trois quantités : le stock actuel, la quantité réservée par les commandes clients ouvertes, et le disponible, qui est leur différence. La confirmation d'un bon de livraison qui ferait passer un article stockable sous zéro est refusée par la base de données, et non signalée par un message que l'on peut ignorer. Chaque mouvement — entrée, sortie, ajustement, transfert entre entrepôts — conserve son motif et sa source.

L'inventaire se mène par sessions numérotées, avec scan de code-barres et double comptage à l'aveugle : le second comptage ne voit pas le premier, et un responsable arbitre les écarts avant application. Les produits passés sous leur seuil deviennent des bons de commande, un par fournisseur préféré. Le module Stock & Produits porte l'ensemble, soldes par produit et par entrepôt compris. Sa limite est nette : ni lot, ni numéro de série, ni date de péremption.

Projets et temps passé : quand découvre-t-on qu'un chantier a coûté plus qu'il n'a rapporté ?

Trop tard, le plus souvent : à la facture finale, ou le jour où le client la conteste. Le symptôme est une heure passée qui n'arrive jamais sur une facture, un achat affecté au mauvais chantier, un avancement estimé de mémoire en réunion.

La procédure cible pose deux objets et un chiffre. Le projet porte ses jalons, ses phases, son budget et son équipe, et se lit en cartes, en tableau, en Kanban ou sur une frise Gantt. L'heure se saisit par projet, marquée facturable ou non, puis passe en « facturé » par lot ; les dépenses s'affectent au même projet. Le chiffre est la marge horaire : la cascade du salaire brut au taux facturé au client, par le coût horaire interne puis le coût chargé, donne le profit par heure.

Un détail décide de l'adoption : les montants sont réservés aux responsables au niveau de la base de données, pas masqués à l'écran — un salarié saisit ses heures sans voir leur valorisation. Le module Projets & Service porte cette partie. Sa limite : ni situation de travaux, ni métré, ni décompte général.

Service client : que promet-on exactement quand on promet de répondre vite ?

Deux délais, et non un seul. Le symptôme d'un service client tenu par messagerie est connu : une demande reçue pendant un congé et jamais reprise, un client qui relance pour savoir si sa demande existe, et aucune réponse à la question « combien de temps mettons-nous à répondre ».

La procédure cible distingue le délai de première réponse et le délai de résolution, chacun fixé par priorité. Les valeurs livrées par défaut au 26 juillet 2026 sont, pour la première réponse, de 1 heure en priorité urgente, 4 heures en haute, 8 heures en moyenne et 24 heures en basse ; pour la résolution, de 2, 8, 24 et 72 heures. Elles se modifient ticket par ticket, et un dépassement se filtre en un clic.

Le reste tient à l'organisation. Un ticket appartient à un département, sa prise en charge est distincte de son assignation, et une note interne ne part jamais au client. Les demandes entrent par trois portes : saisie interne, formulaire public à embarquer sur votre site, portail client. Un ticket résolu sans réponse se ferme automatiquement chaque nuit, et le client peut le rouvrir depuis son portail.

Qui doit avoir un compte pour qu'un processus tienne ?

Toute personne qui écrit dans la donnée. Une approbation à seuil n'existe que si l'approbateur a un compte ; une réception n'est fiable que si le magasinier la saisit lui-même ; un délai de première réponse ne se mesure que si l'agent répond dans l'outil. Un processus dont un maillon reste en messagerie redevient un tableur, avec une étape de plus.

Cette contrainte a un prix quand le logiciel se facture à la personne. Odoo définit l'utilisateur payant ainsi, sur sa page tarifaire consultée le 26 juillet 2026 : « A paying user is usually an employee who has access to the Odoo backend to create, view, or edit documents. » Sa formule Standard y est affichée à 7,25 $ par utilisateur et par mois en engagement annuel, face à un prix barré de 8,95 $, sous cette note de grille : « The discount is valid for 12 months, for initial users ordered. » Le magasinier, l'approbateur et l'agent de support comptent chacun pour un poste, et un budget à trois ans se construit sur 8,95 $.[2]

LINEPROD applique un forfait annuel à utilisateurs illimités : ouvrir un compte au magasinier ne change pas la facture. Différence de modèle, pas jugement de valeur — un tarif par personne suit la taille de l'équipe, un forfait ne bouge pas.

Ce que ces quatre processus ne couvrent pas

Ni la paie, ni la comptabilité générale : ce n'est pas notre métier, et aucune section de cette page n'y touche. La chaîne couverte s'arrête à la porte du bilan et à celle du bulletin de salaire. Sept absences sont structurelles au 26 juillet 2026, et aucune ligne du tableau ci-dessus ne prétend le contraire.

• la paie : aucun bulletin, aucune déclaration CNSS ou AMO, aucun calcul d'IR salarial ;
• la comptabilité générale : aucune écriture, aucun journal, aucune balance, aucun bilan, aucune liasse fiscale, aucun export CGNC ;
• la transmission d'une facture à la Direction Générale des Impôts : rien ne part vers l'administration depuis le produit ;
• la production : ni nomenclature, ni gamme opératoire, ni ordre de fabrication, ni calcul des besoins ;
• la traçabilité par lot, par numéro de série ou par date de péremption ;
• une seule devise par société — dirham, euro ou dollar — et non une devise par document ;
• le paiement en ligne au portail client : le client y déclare son règlement, un opérateur le confirme.

Dans quel ordre déployer ces quatre processus ?

Un seul à la fois, en commençant par celui qui vous coûte le plus cher — et ce coût se lit dans les trois dernières pertes évitables, pas dans une intuition. Une vente annulée faute de disponible désigne le stock ; une facture fournisseur payée deux fois, les achats ; un chantier livré au-delà de son budget d'heures, les projets ; un client qui relance pour savoir si sa demande existe, le service client.

Deux règles tiennent ensuite le déploiement. La première : un processus n'est en place que le jour où la personne qui produit la donnée est celle qui l'écrit — le magasinier saisit sa réception, pas l'assistante le lendemain sur la foi d'un papier. La seconde : un tableur qui survit à côté du logiciel signale un manque, pas une résistance, et la colonne qu'il porte est votre vrai cahier des charges.

Chacun de ces quatre processus aura son article dans ce silo : dimensionnement, ordre de mise en route, pièges de reprise de données. Cette page reste la porte d'entrée et le résumé.

Peut-on garder ses tableurs à côté du logiciel ?

Oui, et c'est un bon signal de départ : un tableur qui survit désigne une colonne absente de l'outil. Le risque n'est pas le fichier, c'est la double saisie, car la même donnée écrite deux fois finit par diverger. Une règle suffit : le tableur calcule et simule, il ne fait jamais autorité sur une quantité, un numéro ou un montant.

Que peut-on reprendre de l'historique existant ?

L'assistant d'import couvre sept jeux de données : clients et contacts, catalogue produits, fournisseurs, employés, opportunités, tâches et contrats, traités par lots de 500 lignes. Les documents à lignes — devis, factures, bons de commande — s'exportent mais ne s'importent pas : une numérotation continue et une piste d'audit ne survivraient pas à une reprise en masse depuis un fichier.

LINEPROD tient-il ma comptabilité et ma paie ?

Ni l'une ni l'autre. Aucune écriture, aucun journal, aucune balance, aucun bilan, aucune liasse fiscale, aucun bulletin de salaire, aucune déclaration CNSS. La chaîne couverte va du devis à l'encaissement et de la commande fournisseur au paiement ; les écritures restent chez votre expert-comptable, à qui LINEPROD transmet un dossier client au format Excel.

Odoo est une marque déposée de son propriétaire. Ce contenu est édité par deadLine SARL ; il n'est ni affilié à cet éditeur, ni approuvé par lui. Les informations le concernant proviennent des sources publiques citées ci-dessus, à leur date de consultation.