ERP sur mesure : le guide complet

Sommaire

1. Pourquoi la question se pose maintenant
2. Make or buy : juger le parc, pas l’étiquette ERP
3. Trois façons de construire, et ce que chacune exige
4. Une stack que quelqu’un d’autre pourra lire
5. Ce qu’il ne faut jamais réécrire
6. L’IA dans un ERP : la fabrication d’abord, le produit ensuite
7. Là où il faut un optimum, pas une phrase
8. Configurateur, alertes, mobile, reporting, journal
9. Auditer, héberger, tenir après la bascule
10. La grille de contrôle avant de signer
11. Budget et calendrier, sans recopier la grille
12. Questions de cadrage

Onze parties, dans cet ordre. Les pages filles du site restent la source des grilles, des facteurs et des clauses : ici, on dit comment les lire ensemble.

Make or buy : juger le parc, pas l’étiquette ERP

On pose trop tôt la question « quel ERP ». On devrait poser « quelles fonctions j’achète, quelles fonctions je fais ». Le parc entier, pas le rectangle « ERP » du schéma directeur. La paie est rarement un avantage concurrentiel. Votre façon d’affecter les équipes le samedi, si. Le déclaratif TVA n’est pas un secret de fabrique. Votre règle de marge sur un client historique, si.

Grille simple, que je sors à chaque cadrage. Ce qui est réglementaire et non différenciant s’achète : paie, comptabilité, liasses, déclaratif social, souvent la facturation électronique côté plateforme. Ce qui porte votre avantage se fait : le modèle de données de votre métier, les écrans que les gens touchent vraiment, les calculs que personne d’autre n’a écrits, l’ordonnancement qui fait tenir l’atelier. Entre les deux, une zone grise — stock, caisse, tournée — qui se tranche à l’usage, pas à l’idéologie.

Pour beaucoup de fonctions, acheter est la bonne réponse. Je le dis sans ravaler ma propre offre. Un moteur de paie français, avec ses avenants de convention, ses cas de saisie unique, ses contrôles URSSAF, est un objet que l’on n’a aucune raison de réécrire. Un grand livre, une liasse, un lettrage bancaire standard : pareil. Le sur-mesure commence où le standard vous fait mentir, ou vous fait attendre une roadmap, ou vous facture au siège un utilisateur qui ouvre l’écran trois fois par mois.

La page sur mesure ou éditeur pose les six critères. Je n’y reviens pas. Ici, je développe ce que cette page-là ne peut pas : vous ne partez pas tous du même endroit. Trois situations de départ, radicalement différentes. Les confondre, c’est signer le mauvais contrat.

Partir de zéro

C’est le cas le plus simple, et le moins risqué, contrairement à l’intuition du dirigeant qui a peur de la page blanche. Pas de reprise sale. Pas d’existant à ménager. Pas de contrat d’éditeur à dénouer. Pas de double vérité pendant six mois. On écrit le métier, on forme, on bascule. Le profil de référence est le A : une société, peu d’utilisateurs, trois ou quatre modules. Mise en service autour de 42 000 € HT — détail des postes sur budget type, je ne recopie pas la grille.

Le risque, ici, n’est pas l’héritage. C’est le périmètre qui s’étale. Chaque « tant qu’on y est » ajoute une semaine, puis un module, puis une intégration. La page blanche attire le catalogue mental de tout ce que l’on a vu chez un concurrent. On cadre serré, on livre un premier processus qui encaisse de l’argent, on élargit. Si vous partez de zéro et que vous voulez « l’ERP complet » avant le premier utilisateur, vous avez déjà quitté le cas simple.

Les tableurs du départ, s’il y en a, ne sont pas un SI. Ce sont des béquilles. On les photographie pour comprendre les règles, on ne les « reprend » pas comme un historique sacré. Un historique de trois ans dans un classeur partagé n’est pas une base. C’est un témoignage. On en extrait les règles, on jette le reste, on avance.

Partir d’un SI éparpillé

C’est le cas majoritaire. Un outil de devis. Un outil de factures. Un tableur de stock. Un SaaS RH. Un logiciel ancien dont la clé USB de dongle est dans un tiroir. Personne n’appelle ça un SI, et c’est pourtant ce qui fait tourner l’entreprise. L’enjeu n’est pas d’ajouter une fonction. C’est de consolider, de reprendre ce qui mérite de l’être, et d’éteindre progressivement ce qui ment.

Le profil de référence glisse vers le B : plusieurs sources, souvent plusieurs sociétés, un interlocuteur unique côté construction. Mise en service autour de 98 000 € HT, récurrent annuel 17 000 € HT. Encore une fois, les postes sont ailleurs. Ici, le risque a un nom : vouloir tout reprendre d’un coup. Six systèmes, un lundi de bascule, un taux de rejet découvert à 11 h. J’ai vu cette scène. Elle est évitable. On reprend un processus, on éteint sa source, on recommence. La consolidation est un régime, pas un week-end.

Ce que l’on reprend se choisit. Les commandes ouvertes, oui. Les brouillons de 2014, non. Les tiers actifs, oui. Les doublons, on les fusionne avant, pas pendant. Un échantillon, un taux de rejet cible, un responsable côté client qui a le droit de dire « cette ligne, on la saisit à la main ». Sans ce responsable, la reprise est un espoir. La page ce qui fait varier le prix chiffre l’amplitude. Je n’en recopie pas la note.

Partir d’un ERP déjà en place

C’est le plus cher, et le plus risqué. Il y a un contrat en cours, parfois une pénalité de sortie. Il y a des données captives, dans un format que l’éditeur documente mal. Il y a un double-run à tenir : l’ancien outil et le nouveau disent la vérité en même temps, le temps de recetter les écarts. Profil B, parfois C — un réseau, 160 000 € à 220 000 € HT de mise en service. Tout ça, plus le coût de l’ancien qui continue de facturer tant qu’on n’a pas coupé.

La page migrer un ERP existe pour ça. Je n’y réécris pas le devis de façade. Je dis ici ce que cette page assume et que l’on n’aime pas entendre : rester est parfois la bonne décision. Si le standard couvre le métier, si la captivité est un inconvénient supportable, si personne n’a six mois devant soi, on reste. On négocie la maintenance. On isole un logiciel métier à côté, plutôt que de tout arracher. Changer pour changer, c’est payer deux fois le même schéma.

Le coût de l’immobilisme existe, sans qu’il faille le dramatiser. Un outil que plus personne ne paramètre. Une licence par siège qui gonfle. Une fin de version annoncée. Un métier qui s’est déplacé et que l’écran standard ignore. Ça se chiffre. Ça ne justifie pas, à soi seul, une migration. Ça justifie de poser la question une fois par an, par écrit, avec les trois situations ci-dessus en tête — pas avec un salon d’éditeurs en fond de diapositive.

Make or buy, donc : au parc entier. Acheter ce qui ne vous distingue pas. Faire ce qui vous distingue. Et, selon que vous partez de zéro, d’un bazar d’outils ou d’un ERP en place, accepter que le même mot « projet ERP » désigne trois animaux différents. La page ERP pour PME tranche souvent en faveur du progiciel. C’est volontaire.

Une stack que quelqu’un d’autre pourra lire

La stack n’est pas un goût. C’est une hypothèse sur qui pourra relire le dépôt dans trois ans. Trois critères, dans cet ordre : durabilité, disponibilité des compétences sur le marché, coût d’exploitation. Le reste — la mode, le framework du salon, le langage que le prestataire « adore » — est un risque que vous financez.

Durabilité : le moteur de données s’exporte. Les contraintes d’intégrité vivent dans la base, pas dans un middleware oublié. Les secrets ne sont pas dans un Slack. Les scripts de déploiement s’exécutent sans l’auteur. Si l’une de ces phrases est fausse, vous n’avez pas une stack. Vous avez un tour de magie.

Compétences : on recrute, ou on change de prestataire, sur un marché réel. Un langage lu par n’importe quelle équipe web. Un moteur relationnel que les DSI connaissent. Pas un runtime confidentiel dont la documentation tient dans un salon privé. Le piège, je l’ai vu signer : le framework exotique qu’un seul atelier maîtrise. Pendant le projet, c’est confortable. À la sortie, c’est une rançon. Vous rachetez les gens, ou vous réécrivez.

Coût d’exploitation : l’hébergement est un poste, pas un nuage. Les sauvegardes se restaurent, ce qui n’est pas la même chose que « elles existent ». Les jobs ont un journal. Le dimanche, une personne que vous pouvez appeler sait relancer. Une stack brillante que personne ne sait tenir coûte plus cher, sur cinq ans, qu’une stack ennuyeuse tenue par deux gens formés.

Le détail de ce que nous livrons — langage, base, clause de réversibilité, hébergement en France en poste distinct — est sur la page technologies. Je ne la réécris pas. Ce que cette page-ci ajoute : exigez, quel que soit le prestataire, que la stack se défende sur les trois critères ci-dessus, à voix haute, devant quelqu’un de votre équipe qui n’est pas le commanditaire. Si personne chez vous ne peut relire, la voie interne de reprise est déjà morte.

Une dernière chose, que les dossiers d’architecture noient. La stack n’est pas le produit. Vos règles de gestion n’ont pas à vivre dans le framework. Elles vivent dans votre modèle, vos tests, vos écrans. Le jour où l’on change de brique d’envoi d’e-mails, le calcul de marge ne doit pas bouger. Si tout est tissé, vous n’avez pas réutilisé des briques. Vous avez fabriqué un nouveau silo.

L’IA dans un ERP : la fabrication d’abord, le produit ensuite

On me demande de « mettre de l’IA » comme on demandait, il y a quinze ans, de « mettre du web ». La phrase ne veut rien dire tant qu’on n’a pas séparé deux objets que les dossiers commerciaux collent exprès. L’IA comme moyen de fabriquer le logiciel. L’IA comme fonction à l’intérieur du logiciel. La rupture, celle qui rend ce guide possible, est la première. Pas la seconde.

La rupture est dans l’atelier, pas dans le catalogue

L’IA générative a fait baisser le coût d’écriture du sur-mesure. Un écran de réception, un import, un état de stock, une API documentée : ce qui se chiffrait en mois se tient en semaines, avec des tests, avec une revue. Ce n’est pas une promesse de salon. C’est ce que l’on constate quand un binôme outillé cesse de tout taper comme en 2012. Le sur-mesure redevient pertinent aujourd’hui pour cette raison-là, bien plus que pour les badges « IA native » collés sur des progiciels.

Les fonctions « IA » vendues dans les produits sont un argument de catalogue. Parfois utiles. Souvent un champ de recherche approximatif, un résumé de fiche, un chatbot qui ne voit pas vos stocks. Elles ne changent pas l’équation économique d’un projet. Ce qui la change, c’est que faire écrire l’outil de votre métier n’est plus réservé à ceux qui ont un million devant eux. La médiane publique que l’on a lue plus haut décrit l’autre marché — l’éditeur, le marché notifié. Notre grille décrit celui-ci. L’IA de fabrication est ce qui a rapproché les deux, du côté de l’écriture, pas du côté de la licence.

Je tiens cette thèse sans l’édulcorer. Si demain les modèles n’aidaient plus à écrire du code, le sur-mesure redeviendrait le luxe d’avant. Si demain un éditeur colle un modèle sur sa saisie, vous n’aurez pas pour autant la propriété du code, ni la règle de marge que votre métier exige. Ne confondez pas un accélérateur d’atelier et un module de plus sur la facture.

Dans le produit, l’IA a sa place sur le génératif et le non structuré

Là, oui. J’en ai mis en production. Extraction depuis des pièces non structurées : une facture fournisseur en PDF tordu, un courrier de résiliation, une photo de chantier avec un numéro de lot écrit au marqueur. Rédaction et synthèse : un compte-rendu d’intervention, une relance, un résumé de dossier client pour le commercial qui n’a pas vingt minutes. Recherche en langage naturel dans l’historique — « les commandes de tel chantier qui ont glissé » — sans forcer l’utilisateur à connaître le nom de la colonne. Assistance à la saisie : proposer le compte, le tiers, le libellé, à partir de ce qui est déjà là. Classement : cette pièce va dans ce dossier, cette demande va vers cette équipe.

Dans tous ces cas, l’entrée n’est pas une table, ou la sortie est du langage. L’humain relit. L’erreur a un coût limité, ou un circuit de correction. On journalise la proposition et la décision. On ne fait pas de l’extraction une écriture comptable directe le premier jour. On met un taux de rejet, comme pour une reprise. On monte en confiance. C’est un métier d’intégration, pas un miracle.

La photo de chantier est un bon test. Le modèle lit un numéro, une date, un état. L’opérateur confirme. L’ERP enregistre une ligne propre, datée, affectée, dans le modèle que l’on a programmé. L’IA n’a pas « géré le chantier ». Elle a transformé du désordre en structure. Ensuite, les règles — qui a le droit de facturer, quel avancement ouvre quelle situation — s’exécutent sans modèle.

Ce qu’il ne faut pas remplacer par un agent

Un calcul de prix. Une règle de gestion. Un contrôle de cohérence. Une affectation. Un calcul de marge. Cela se programme, se teste, se rejoue à l’identique, s’audite. Confié à un agent, c’est plus cher, plus lent, non déterministe, et impossible à défendre devant un commissaire aux comptes ou un auditeur.

Je l’ai refusé, noir sur blanc, sur des cadrages où l’on me vendait « l’agent qui fera les tarifs ». Un tarif, le lundi suivant, doit sortir le même chiffre pour les mêmes entrées. Un agent ne signe pas ça. Il approxime. Il varie. Il hallucine une remise. Il oublie une ligne de barème. Il coûte un appel à chaque devis. Et quand le commissaire demande « montrez-moi pourquoi ce client a eu 7 % », vous n’avez pas un test. Vous avez un prompt.

L’affectation d’un technicien à une urgence, si elle tient dans des règles — compétence, zone, astreinte, délai de route — se programme. Si vous la donnez à un agent « parce que c’est plus souple », vous avez acheté de l’imprévisible au moment où le client hurle. La souplesse que l’on veut est dans les règles que l’on sait changer, versionnées, recettées. Pas dans un modèle qui a « jugé ».

Le contrôle de cohérence — une commande sans stock, une situation de travaux supérieure au marché, une TVA qui ne colle pas au journal — n’est pas une conversation. C’est un refus. Un agent qui « explique » au lieu de bloquer est un copilote de fraude involontaire. On bloque. On affiche pourquoi. On journalise. On corrige la saisie. Point.

Plus cher : chaque appel se facture, ou se provisionne en GPU, alors qu’un calcul déterministe est de la CPU négligeable. Plus lent : un aller-retour réseau, un contexte à construire, une relance si la réponse est mal formée. Non déterministe : deux exécutions, deux textes, parfois deux décisions. Inauditable : pas de preuve, pas de rejeu bit à bit, pas de recette automatisée qui tienne. Devant un auditeur, « le modèle a considéré » n’est pas une réponse. C’est un aveu.

Règle à tenir

Si la règle est exprimable, on la programme. L’IA intervient quand l’entrée n’est pas structurée ou quand la sortie est du langage. Phrase courte. Je la fais écrire dans la matrice d’engagement. Tout le reste est du théâtre.

Exprimable, ça veut dire : un métier peut la dire, un développeur peut la tester, un autre développeur peut la relire, un auditeur peut la suivre sur un exemple. « On fait un geste commercial au-delà de tel encours, après accord du DAF » est exprimable. « On sent si le client est fidèle » n’est pas une règle, c’est une conversation. La conversation peut aider la saisie. Elle ne décide pas de l’encours.

Ce que ça change dans le choix d’un prestataire

Demandez, par écrit, ce qui est déterministe et ce qui est génératif dans ce qu’on vous vend. Faites lister les fonctions. En face de chacune : programme, ou modèle. Si la liste ne vient pas, ou si tout est « IA native », vous n’avez pas une architecture. Vous avez un argument commercial. « IA native » sans cette réponse est un autocollant.

Demandez aussi le coût par appel, le modèle, le lieu d’hébergement des inférences, ce qui sort de vos murs, ce qui reste. Une pièce d’identité passée dans un modèle hors de France n’est pas un détail. Un historique d’affaires passé dans un entraînement dont vous n’avez pas le contrat n’est pas un détail. Le génératif a une géographie et un avocat. Le programmatique aussi, mais on sait où il tourne : chez vous, sur le poste d’hébergement que vous tenez.

Enfin, demandez les tests. Un calcul de prix sans jeu de tests n’est pas un calcul, c’est une opinion dans du code. Un extracteur sans taux de rejet n’est pas un extracteur, c’est une démo. Les deux peuvent cohabiter dans le même produit. Ils ne se rendent pas les mêmes comptes. C’est précisément pour ça qu’on les sépare.

Configurateur, alertes, mobile, reporting, journal

Cinq oublis de cadrage. Pas glorieux. Pas optionnels. On les pose dès le premier document, ou ils arrivent en palier surprise, donc plus cher, donc trop tard.

Le configurateur

Ce que le client — le vôtre, ou le vôtre en interne, l’admin métier — peut paramétrer seul, sans ticket de développement. Barèmes, textes de documents, habilitations simples, listes, seuils d’alerte. Chaque chose que l’on rend configurable est un peu plus chère à écrire au départ, et beaucoup moins chère ensuite. Chaque chose que l’on n’ose pas rendre configurable reviendra en avenant. Le bon cadrage nomme la frontière : ceci se clique, ceci se développe. La frontière floue est une pompe à jours.

Ce que ça coûte de le rendre possible : un modèle de paramètres, des droits, un historique des changements, des valeurs par défaut qui ne cassent pas la production. Ce n’est pas un « écran admin » bricolé. C’est un produit dans le produit. On le dimensionne. On ne le promet pas « s’il reste du temps ».

Alertes et notifications

Sur règles métier et sur seuils. Un encours qui saute. Un lot qui expire. Une tournée qui dérape. Un chantier sans situation depuis trop longtemps. Sans ça, l’ERP est un tiroir. Avec ça, il est un contremaître. Les règles sont programmatiques — voir plus haut. Les canaux (écran, mail, mobile) sont de l’intégration. Le volume est un sujet : trop d’alertes, plus personne ne lit. On cadre les cinq qui font mal, on ajoute ensuite.

Mobile et terrain, y compris hors-ligne

Un navigateur sur téléphone n’est pas une application de quai. Gros boutons, scan, photo, signature, une main occupée. Et la question que l’on fuit : que se passe-t-il quand il n’y a plus de réseau. Un chantier, une cave, une tournée. L’outil doit écrire localement, puis se réconcilier. Conflits, photos en attente, stock touché des deux côtés. Ce n’est pas un interrupteur. C’est un facteur, publié + 12 000 € à 25 000 € HT. Le récit complet est sur ce qui fait varier le prix. Ici, je dis seulement : si vous avez du terrain, posez la question au cadrage, pas au palier 3.

Reporting et pilotage

Les écrans opérationnels ne sont pas le cockpit. Un responsable a besoin de trois chiffres le lundi, pas d’exporter Excel parce que « on verra bien ». On nomme les décisions que le rapport doit éclairer. On ne promet pas « un datawarehouse ». On livre les vues qui évitent le tableur parallèle, qui est le premier concurrent de tout ERP, y compris le vôtre.

Le journal d’audit

Qui a vu, qui a changé, quand, avant/après, depuis quelle machine. Pas pour faire plaisir à un RSSI de passage. Pour vous, le jour où une facture a bougé, le jour où un prix d’achat a glissé, le jour où un droit a été prêté. Un ERP sans journal est un outil de bureautique. Un journal que personne ne sait interroger est un décor. On le cadre avec les rôles, pas après l’incident.

Ces cinq postes déplacent le prix. Ils ne s’empilent pas à l’infini : au-delà de quelques facteurs majeurs, on rechiffre le profil. La règle est sur la page des facteurs, section forfait ou régie comprise. Je n’y touche pas.

La grille de contrôle avant de signer

Que vous choisissiez un atelier, le nôtre ou un autre, ou que vous arbitriez encore avec un intégrateur, ces points se demandent. Chacun avec ce qu’une bonne réponse contient. Les dix questions d’audit d’intégrateur et les rubriques du cahier des charges restent la check-list opérationnelle. Ici, la grille de contrôle du constructeur.

Propriété du code — le point numéro un

Bonne réponse : vous possédez le dépôt, palier après palier, pas « à la fin si tout va bien ». Historique Git, pas un zip. Documentation écrite pour un successeur. Scripts de déploiement exécutables sans l’auteur. Toute autre réponse — licence d’utilisation, « vous avez l’usage », « on verra à la recette finale » — est une clause de captivité, quel que soit le sourire.

Clause de sortie et réversibilité

Bonne réponse : dépôt du code chez un tiers si vous le voulez, documentation d’exploitation, accompagnement au transfert, export des données dans un format documenté, testé pendant la recette, pas promis pour le jour de la dispute. Une réversibilité jamais exercée n’en est pas une. Demandez la date du dernier test, même sur un projet voisin anonymisé, ou demandez à le faire sur le vôtre avant de clore le premier palier.

Garantie

Bonne réponse : une durée, un périmètre (ce qui est couvert : défauts de ce qui a été recetté ; ce qui ne l’est pas : les avenants non faits, les données sales, le mauvais usage), un canal, un délai. « On est là » n’est pas une garantie. Une garantie qui couvre « tout » ne couvre rien : elle n’a pas de bord, donc pas de budget, donc pas de priorité.

SLA chiffré, avec pénalités

Bonne réponse : GTR, plage, exclusions, calcul de disponibilité, pénalités qui font mal assez pour que l’on dimensionne l’équipe. Des pénalités symboliques sont un décor. Pas de SLA chiffré, pas d’astreinte déguisée en « on gardera un œil ».

« IA native » : la question de la section 6

Bonne réponse : le tableau déterministe / génératif, fonction par fonction. Les tarifs, marges, affectations, contrôles : du programme. L’extraction, la rédaction, la recherche en langue, l’aide à la saisie : du modèle, avec relecture et journal. Pas de tableau, pas d’architecture. Un demo day n’est pas une réponse.

Forfait ou régie

Bonne réponse : ce que chacun transfère comme risque, dit à voix haute. Le forfait transfère le risque d’estimation vers le prestataire ; ça se paie, ce n’est pas un mode moralement supérieur. La régie vous laisse le risque de périmètre ; le TJM publié va de 700 € HT à 900 € HT. « Je ne sais pas » est une réponse honnête au cadrage ; après le cadrage, ce n’en est plus une. Le développement est sur forfait ou régie.

Réutilisation open source et licences

Bonne réponse : la liste des briques, la licence de chacune, le cloisonnement avec votre code métier, qui paie les montées de version. Une slide « on s’appuie sur l’open source » sans liste est de la littérature.

Sous-traitance et localisation des équipes

Bonne réponse : qui écrit, où, sous quel contrat, qui a accès aux données. Un « nous » qui désigne trois sociétés et un fuseau à +5 h n’est pas un nous. Ce n’est pas une question morale. C’est une question d’astreinte, de langue du métier, de droit applicable, de qui se présente le jour où ça casse. On l’écrit.

Si ces huit réponses tiennent, le reste — la méthode, les paliers, le ton — se discute. Si l’une d’elles glisse, surtout la première, le prix n’a plus d’importance. Vous achetez un loyer.

Questions de cadrage