DEV Community: Termi24

Migrer d'Excel vers un ERP : le guide étape par étape

Termi24 — Sun, 21 Jun 2026 19:37:20 +0000

Quand Excel ne suffit plus

Excel est un outil formidable pour démarrer, prototyper un calcul ou suivre une liste. Mais à mesure qu'une entreprise grandit, le tableur atteint ses limites. La migration excel erp devient alors moins un projet informatique qu'une décision de gestion : il s'agit de fiabiliser la donnée qui pilote toute l'activité.

Les signaux qui ne trompent pas

Plusieurs symptômes indiquent qu'un tableur a fait son temps :

Des fichiers qui se multiplient et divergent : stock_v3_FINAL_corrigé.xlsx circule par e-mail, et plus personne ne sait quelle version fait foi.
Des erreurs manuelles invisibles : une formule écrasée, une plage mal étendue, un copier-coller décalé — et un chiffre faux se propage sans alerte.
Aucune piste d'audit : impossible de savoir qui a modifié quoi, ni quand. Un point critique dès qu'on parle de comptabilité ou de conformité.
Pas de temps réel ni de collaboration fiable : deux personnes ne peuvent pas travailler sereinement sur la même source, et les indicateurs sont toujours en retard.
Pas de lien entre les métiers : le commercial, le stock et la facturation vivent dans des fichiers séparés, ressaisis à la main.

Un ERP résout précisément ces problèmes : une base de données unique, partagée, tracée, où chaque module (ventes, achats, stock, finance) alimente automatiquement les autres.

Les étapes d'une migration réussie

Une migration excel erp ne s'improvise pas. Elle se découpe en quatre grandes phases, à mener dans l'ordre.

1. Cadrage et périmètre

Avant de toucher au moindre fichier, posez le cadre :

Quels processus migrer en premier ? Inutile de tout basculer d'un coup. Identifiez le périmètre prioritaire (souvent le couple ventes-stock, ou la facturation).
Quels sont les objectifs mesurables ? Réduire les ressaisies, fiabiliser les niveaux de stock, accélérer la clôture comptable. Traduisez-les en indicateurs suivis avant/après.
Qui pilote ? Désignez un référent métier par domaine. C'est lui qui validera les règles de gestion et les jeux de données.

Ce cadrage évite l'effet « usine à gaz » où l'on cherche à tout reproduire à l'identique, y compris les bricolages Excel hérités.

2. Reprise et nettoyage des données

C'est l'étape la plus sous-estimée — et la plus déterminante. Un ERP nourri de données sales restera sale.

Auditez l'existant : doublons de clients, références produits incohérentes, formats de dates mélangés, champs vides.
Nettoyez avant d'importer : standardisez les unités, les codes, les intitulés. Profitez-en pour archiver ce qui n'a plus d'utilité.
Définissez les correspondances (mapping) : chaque colonne du tableur doit pointer vers le bon champ de l'ERP.
Importez par lots et vérifiez : commencez par les données de référence (clients, fournisseurs, articles), puis les flux (commandes, factures).

Cette reprise concerne aussi bien les contacts qui alimenteront le module CRM que les articles destinés à la gestion de stock.

3. Paramétrage et configuration

L'ERP doit refléter votre fonctionnement réel :

Droits et rôles : qui voit quoi, qui valide quoi. C'est aussi le moment d'appliquer les bonnes pratiques RGPD sur l'accès aux données personnelles.
Règles de gestion : numérotation des pièces, taux de TVA, circuits de validation, seuils d'alerte de stock.
Connexions entre modules : une commande validée doit déduire le stock et préparer la facture, sans ressaisie.

Veillez à conserver la conformité comptable : un module de finance ou de facturation digne de ce nom doit produire un fichier des écritures comptables (FEC) exportable pour l'administration.

4. Tests et bascule (go-live)

Recette sur jeu de données réel : faites tourner un cycle complet (devis → commande → livraison → facture) et comparez avec Excel.
Choisissez votre stratégie de bascule : big bang (tout d'un coup) pour les petites structures, ou progressive module par module pour limiter le risque.
Prévoyez une période de double saisie courte : rassurante, mais à borner dans le temps pour ne pas épuiser les équipes.
Figez une date d'arrêt d'Excel : sans échéance ferme, le tableur survit indéfiniment et la migration échoue à moitié.

Les pièges classiques à éviter

Vouloir tout migrer d'un coup, y compris les processus obsolètes. La migration est l'occasion de simplifier, pas de cloner ses mauvaises habitudes.
Négliger la qualité des données : c'est la première cause de rejet par les utilisateurs (« l'outil est faux »).
Sous-estimer la reprise d'historique : décidez clairement ce que vous reprenez (soldes, en-cours) et ce que vous archivez en lecture seule.
Oublier la réversibilité : conservez une sauvegarde figée des fichiers Excel d'origine, horodatée.
Acheter trop de fonctionnalités d'un coup : commencez par le cœur, étendez ensuite. Les capacités de pilotage et d'analyse viennent enrichir le socle une fois la donnée propre.

Conduite du changement : embarquer les équipes

Un projet d'ERP réussi est avant tout un projet humain. Un outil parfait que personne n'utilise ne sert à rien.

Communiquez le « pourquoi » : montrez les irritants Excel que l'ERP supprime (ressaisies, erreurs, fichiers perdus).
Formez sur les cas réels des utilisateurs, pas sur des démos théoriques.
Désignez des référents internes capables de répondre aux questions du quotidien.
Mesurez et célébrez les gains : temps gagné, erreurs évitées, indicateurs enfin fiables et en temps réel.

L'adhésion se gagne quand chacun constate que l'ERP lui simplifie la vie — pas quand il a l'impression qu'on lui impose une contrainte de plus.

Découvrir eyeot

eyeot est un ERP français qui couvre le CRM, le stock, la facturation, la finance et bien d'autres domaines au sein d'une base unique. L'objectif : remplacer la mosaïque de tableurs par une source de vérité partagée et traçable.

Vous envisagez une migration excel erp pour votre organisation ? Le compte particulier gratuit d'eyeot (un utilisateur, tous les modules, sans carte bancaire, sans limite de durée) permet de tester l'outil sur vos propres données, immédiatement, via erp.eyeot.fr/sign-up. Une bonne occasion de cadrer votre projet et d'évaluer concrètement la transition.

Factur-X : comprendre la facture électronique hybride

Termi24 — Sun, 21 Jun 2026 19:28:26 +0000

Qu'est-ce que Factur-X ?

Factur-X est le format français de facture électronique dite hybride. Son principe est simple mais astucieux : un seul fichier sert à la fois l'humain et la machine. Concrètement, une facture Factur-X est un document PDF parfaitement lisible à l'écran ou à l'impression, dans lequel est embarqué un fichier XML contenant les mêmes informations sous forme structurée.

Cette dualité résout le vieux dilemme de la dématérialisation. Pendant des années, les entreprises ont échangé des PDF que le destinataire devait ressaisir ou « scanner » par OCR, avec son lot d'erreurs. À l'inverse, les flux EDI purement structurés étaient illisibles sans outil dédié. Factur-X réconcilie les deux mondes : le comptable voit une facture normale, tandis que son logiciel lit directement les données pour les intégrer sans saisie manuelle.

Le format a été conçu conjointement par le Forum National de la Facture Électronique français (FNFE-MPE) et son homologue allemand, ce qui en fait un standard franco-allemand interopérable.

L'architecture hybride : PDF/A-3 + XML CII

Le PDF/A-3, la couche lisible

Le conteneur de Factur-X n'est pas un PDF ordinaire mais un PDF/A-3 (norme ISO 19005-3). Cette variante du PDF est dédiée à l'archivage long terme et présente une caractéristique décisive : elle autorise officiellement l'intégration de pièces jointes à l'intérieur du document. C'est ce qui permet de loger le fichier XML directement dans le PDF, sous un nom de fichier normalisé (factur-x.xml).

Le PDF/A-3 garantit aussi que le rendu visuel restera fidèle dans dix ou quinze ans, polices et mise en page incluses — un atout pour la conservation probatoire.

Le XML CII, la couche structurée

Les données structurées s'expriment en XML au format CII (Cross Industry Invoice), une syntaxe normalisée par l'UN/CEFACT. On y retrouve, balisées une à une, toutes les informations de la facture : identité du vendeur et de l'acheteur, numéro, dates, lignes de détail, bases et taux de TVA, totaux, conditions de paiement.

En cas de divergence, c'est le XML qui fait foi sur le plan du traitement automatisé : le logiciel comptable s'appuie sur lui, pas sur le visuel. Le PDF reste la représentation de référence pour l'œil humain.

La norme EN 16931, socle européen

Au-dessus de la syntaxe se trouve la sémantique, définie par la norme européenne EN 16931. Issue de la directive 2014/55/UE, elle établit un modèle sémantique commun : la liste des informations qu'une facture électronique doit ou peut contenir et leur signification, indépendamment du langage technique employé.

Factur-X est l'une des implémentations de cette norme. Une facture conforme au cœur de l'EN 16931 sera comprise de la même manière dans toute l'Union européenne, qu'elle soit exprimée en CII ou dans la syntaxe alternative UBL. C'est cette convergence sémantique qui rend l'interopérabilité possible entre éditeurs, pays et plateformes.

Les profils Factur-X

Toutes les factures n'ont pas le même besoin de richesse de données. Factur-X définit donc plusieurs profils, du plus léger au plus complet :

MINIMUM : données d'en-tête essentielles, surtout utiles pour le pré-remplissage comptable.
BASIC WL (without lines) : totaux et TVA, sans le détail des lignes.
BASIC : ajoute le détail des lignes de facturation.
EN 16931 : le profil de référence, qui couvre l'intégralité du socle sémantique européen.
EXTENDED : enrichi pour les cas métier complexes (multi-livraisons, secteurs spécifiques).

Plus le profil est élevé, plus l'automatisation côté destinataire est complète — sans saisie ni rapprochement manuel.

Factur-X et ZUGFeRD : cousins germains

La confusion est fréquente, et pour cause. ZUGFeRD est le nom allemand du même standard. Depuis ZUGFeRD 2.x et Factur-X 1.0, les deux formats sont techniquement identiques : une facture émise en Factur-X est lue sans difficulté par un système attendant du ZUGFeRD, et réciproquement.

Les différences relèvent surtout de la gouvernance et de la dénomination des profils. Côté allemand, ZUGFeRD ajoute notamment un profil XRECHNUNG dédié au secteur public. Pour un éditeur français, retenir l'essentiel suffit : produire du Factur-X conforme, c'est produire un document compatible avec l'écosystème allemand.

Émettre et recevoir une facture Factur-X

Émettre

Générer une facture Factur-X suppose de produire simultanément la représentation visuelle et les données structurées, puis de les fusionner dans un PDF/A-3 valide. Les étapes typiques :

Constituer le modèle sémantique de la facture (vendeur, acheteur, lignes, TVA, totaux).
Sérialiser ces données en XML CII selon le profil retenu.
Mettre en page le PDF/A-3 lisible.
Embarquer le XML comme pièce jointe normalisée dans le PDF.

Un logiciel de facturation intégré réalise ces étapes de façon transparente : l'utilisateur clique sur « émettre la facture » et obtient un fichier hybride conforme, prêt à être envoyé. Cela vaut aussi pour les pièces amont du cycle, comme un devis que l'on transforme ensuite en facture.

Recevoir

À la réception, le traitement est inversé : le logiciel extrait le XML du PDF, le valide contre le profil et la norme EN 16931, puis intègre automatiquement les écritures et le rapprochement (commande, bon de réception, paiement). Le PDF, lui, peut être classé en GED pour la conservation. Le gain est immédiat : fin de la ressaisie, réduction des erreurs et accélération du cycle de validation.

Factur-X dans la réforme française

Factur-X tient une place centrale dans la généralisation de la facture électronique entre entreprises. La réforme retient trois formats socles : CII, UBL et Factur-X (l'hybride). Les flux transitent par des Plateformes de Dématérialisation Partenaires, ou PDP, chargées d'émettre, transmettre et recevoir les factures.

Le calendrier annoncé prévoit une obligation de réception pour toutes les entreprises, puis une obligation d'émission échelonnée selon la taille. Anticiper ce changement, c'est s'assurer que ses outils savent déjà produire et lire du Factur-X — et que les données comptables remontent proprement dans le module finance, jusqu'aux obligations comme le FEC. (Le calendrier réglementaire pouvant évoluer, vérifiez toujours les échéances officielles en vigueur.)

Aller plus loin avec eyeot

eyeot est un ERP français qui couvre le cycle complet devis → commande → facture, avec un module de facturation et un module finance reliés à la gestion documentaire. Si la facture électronique hybride fait partie de vos chantiers, le compte particulier 100 % gratuit (un utilisateur, tous les modules, sans carte bancaire) vous permet de tester l'outil immédiatement : inscription sur erp.eyeot.fr/sign-up. Une bonne occasion de préparer sereinement la transition vers Factur-X.

L'ERP à l'ère des agents IA : pourquoi le protocole MCP change la donne

Termi24 — Sun, 21 Jun 2026 19:26:36 +0000

Des API à la conversation : un nouveau mode d'accès à l'ERP

Pendant vingt ans, intégrer un logiciel de gestion à un autre outil supposait d'écrire du code : appeler une API REST, gérer l'authentification, parser les réponses, maintenir le tout à chaque évolution. Cette approche reste solide, mais elle exclut de fait tous les utilisateurs qui ne sont pas développeurs.

L'arrivée des agents IA — ChatGPT, Claude, Cursor et leurs équivalents — change la donne. Ces assistants ne se contentent plus de répondre à des questions : ils peuvent agir, c'est-à-dire déclencher des opérations dans un système tiers. Pour qu'un agent crée un devis, lise un stock ou planifie une intervention dans un ERP, il lui faut un langage commun avec ce logiciel. C'est précisément le rôle du protocole MCP.

Le protocole MCP, en clair

Le MCP (Model Context Protocol) est un protocole ouvert qui standardise la connexion entre un modèle de langage et des sources de données ou des outils externes. On le compare souvent à un « port universel » : plutôt que de réinventer une intégration sur mesure pour chaque assistant, un éditeur expose une seule fois ses capacités via un serveur MCP, et n'importe quel agent compatible peut s'y connecter.

Concrètement, un serveur MCP publie une liste d'outils (tools). Chaque outil décrit une action possible — « créer un client », « lister les factures impayées », « consulter le tableau de bord » — avec ses paramètres attendus. L'agent IA découvre cette liste, choisit l'outil pertinent en fonction de la demande de l'utilisateur, le remplit et reçoit le résultat structuré.

Comment ça marche concrètement

Un utilisateur écrit dans son assistant : « Crée un devis de 1 500 € pour le client Durand et envoie-le. » L'agent :

Découvre les outils exposés par le serveur MCP de l'ERP.
Sélectionne l'outil de création de devis et déduit les paramètres du message.
Appelle l'outil via le serveur, qui exécute l'opération comme le ferait l'interface web.
Restitue une confirmation lisible et, le cas échéant, le lien vers le document.

L'atout majeur : ces outils peuvent être générés automatiquement à partir de la spécification OpenAPI de l'ERP. Chaque route documentée devient un outil exploitable par l'agent, sans réécriture manuelle. eyeot adopte cette logique : son serveur MCP dérive ses outils de l'API existante et achemine chaque appel à travers la même pile que l'interface — préservant authentification, périmètre de données et journal d'audit.

Authentification : ouvrir l'ERP aux agents sans baisser la garde

Donner à une IA les clés d'un système de gestion soulève immédiatement une question de sécurité. Un ERP contient des données financières, RH et clients : l'accès agentique ne peut pas s'appuyer sur un simple mot de passe partagé.

Le standard qui s'impose est OAuth 2.1, avec plusieurs modes adaptés au contexte :

Authorization Code + PKCE : l'utilisateur s'authentifie dans son navigateur et autorise explicitement l'agent. Le jeton délivré est de courte durée et renouvelable.
Device Grant : pensé pour les agents en ligne de commande ou les applications sans navigateur intégré (un assistant de bureau, par exemple). L'utilisateur valide l'accès sur un autre écran.
Clés d'API émises par l'organisation, au périmètre maîtrisé, pour les intégrations de service.

Dans tous les cas, le principe reste le même : l'agent hérite des permissions de l'utilisateur qui l'a autorisé, jamais davantage. Un assistant connecté au compte d'un commercial ne pourra pas consulter la paie. Cette cohérence repose sur un contrôle d'accès fin, appliqué à chaque requête, et sur la multi-location stricte des données.

Les garde-fous indispensables d'un ERP agentique

Un agent IA est puissant mais faillible : il peut mal interpréter une consigne, répéter une action, ou agir trop vite. Un ERP prêt pour l'IA doit donc intégrer des mécanismes de sécurité conçus pour ce nouveau mode d'usage.

Idempotency : ne pas créer deux fois la même facture

Si un agent renvoie une requête après un délai réseau, il risque de dupliquer une opération — deux factures, deux commandes. La parade est l'idempotency : l'agent joint un identifiant unique (Idempotency-Key) à chaque requête sensible. Si le serveur reçoit deux fois la même clé, il renvoie le résultat initial sans réexécuter l'action. Une seule facture est créée, quoi qu'il arrive.

Dry-run : simuler avant d'écrire

Avant de valider une opération à fort impact, il est précieux de pouvoir prévisualiser ses effets sans rien modifier. Le mode dry-run (souvent un en-tête X-Dry-Run) exécute la logique métier, capture ce qui aurait changé — mutations, notifications, déclenchements — puis annule tout. L'agent peut ainsi annoncer « voici ce que cette action va produire » avant de demander une confirmation finale.

Audit et RBAC : traçabilité et permissions

Chaque action déclenchée par un agent doit être tracée comme n'importe quelle action humaine : qui, quoi, quand, depuis quel jeton. Un journal d'audit horodaté — idéalement chaîné cryptographiquement — garantit qu'aucune opération automatisée n'échappe au contrôle. Côté droits, le RBAC filtre en amont ce que l'agent peut faire. Pour les décisions automatisées touchant des personnes, le cadre du RGPD (notamment l'article 22) impose par ailleurs de garder un humain dans la boucle.

À ces garde-fous s'ajoute une logique de lecture seule par défaut : un agent peut consulter et informer librement, tandis que les opérations d'écriture restent conditionnées à une autorisation active. Une frontière nette entre « lire » et « agir ».

Cas d'usage concrets

Une fois l'ERP rendu pilotable par IA, les usages se multiplient :

Reporting conversationnel : « Quel est mon chiffre d'affaires du mois et mes impayés ? » sans ouvrir le moindre tableau de bord.
Saisie assistée : dicter une opportunité, un client ou un ticket à l'oral, l'agent structurant l'information.
Orchestration cross-module : relier devis, stock et facturation en une seule consigne, en s'appuyant sur l'intelligence cross-module de l'ERP.
Connexion à l'écosystème : combiner l'ERP à d'autres outils via des intégrations déclenchées par l'agent.

L'objectif n'est pas de remplacer l'interface, mais d'offrir un canal supplémentaire, plus rapide pour certaines tâches répétitives ou exploratoires.

Découvrir eyeot

eyeot est un ERP français pensé pour cette nouvelle génération d'usages : son serveur MCP expose les opérations métier aux agents compatibles, avec authentification OAuth, idempotency, mode dry-run et journal d'audit intégrés. L'accès agentique respecte les mêmes permissions et la même isolation que l'interface web.

Si vous souhaitez expérimenter le pilotage d'un ERP depuis votre assistant favori, le compte particulier est 100 % gratuit, en permanence — un utilisateur, tous les modules, sans carte bancaire. Créez votre compte en quelques minutes sur erp.eyeot.fr/sign-up et éprouvez l'outil en conditions réelles.