Le logiciel qui porte votre activité, pas celui d’un autre métier

Trois réponses possibles, et une seule est la vôtre

Un projet de CRM ou d’ERP se joue presque entièrement sur cette question, et elle se tranche avant le devis, pas pendant le projet.

• Configurer un progiciel. Votre fonctionnement ressemble à celui de beaucoup d’entreprises de votre taille : un outil existant, bien paramétré, fait le travail. C’est le cas le plus fréquent, et le moins cher.
• L’étendre. L’essentiel est standard, mais deux ou trois choses vous sont propres — une règle de tarification, un circuit de validation, un document particulier. On garde la base et on développe ce qui manque.
• Écrire. Votre façon de travailler est ce qui vous distingue de vos concurrents. La plier à un progiciel reviendrait à renoncer à ce qui vous fait gagner.

Le travers courant est de choisir la troisième réponse par goût, ou la première par économie, sans avoir posé la question. Nous la posons.

Dolibarr : notre point de départ le plus fréquent

C’est la base sur laquelle nous construisons le plus souvent, et pour des raisons qui n’ont rien de techniques.

C’est un logiciel libre : pas de droit d’usage par utilisateur qui augmente à chaque embauche, pas de décision d’éditeur qui vous impose une migration ou un nouveau tarif. Il réunit l’ERP et le CRM dans le même outil — clients, devis, commandes, stocks, factures et suivi commercial partagent les mêmes données, au lieu de vivre dans deux logiciels qu’il faut ensuite réconcilier.

Il est modulaire : on n’active que ce qui sert, ce qui évite d’imposer à vos équipes un outil dont neuf écrans sur dix ne les concernent pas. Et il est écrit en PHP, comme une grande partie de ce que nous exploitons déjà.

Étendre par modules, jamais en modifiant le cœur

C’est le point qui décide de la vie de votre installation sur dix ans, et il mérite d’être dit clairement.

Modifier directement le code d’un progiciel pour l’adapter est rapide, et c’est la façon la plus sûre de se retrouver bloqué sur une vieille version : la mise à jour suivante écrase les modifications, ou refuse de s’appliquer. On voit régulièrement des installations figées depuis des années, avec les failles que cela suppose, parce que personne n’ose plus les mettre à jour.

Nous développons donc des modules, dans les points d’extension prévus pour cela. Vos spécificités vivent à part, le cœur reste celui de l’éditeur, et une mise à jour redevient une opération ordinaire.

Quand le sur-mesure s’impose vraiment

Quand la règle métier ne rentre pas. Une tarification qui dépend de six paramètres, un circuit de validation propre à votre secteur, une contrainte réglementaire qu’aucun progiciel généraliste ne connaît : à partir d’un certain point, contorsionner l’outil coûte plus cher que d’écrire ce qu’il faut.

Nous développons alors en PHP avec Symfony, en Python, en Java ou Kotlin, ou en Go selon ce que l’application doit faire — et avec la même façon de travailler que nos autres applications métier : le vocabulaire de votre métier dans le code, les règles isolées de la technique, et des tests qui permettent de modifier sans casser.

Où que vous soyez en France

Nos équipes et nos machines sont à Nantes ; nos clients ne le sont pas forcément. Un projet de CRM ou d’ERP se mène très bien à distance — ateliers en visioconférence, environnement de recette accessible en ligne, formation par partage d’écran — et c’est ainsi que nous travaillons avec des entreprises dans toute la France.

Ce que la proximité apporte réellement, c’est autre chose : voir les gens travailler, comprendre pourquoi ce tableur existe et ce qu’il compense. Cela se traite en une ou deux journées sur site, au début du projet, et cela vaut le déplacement où qu’il soit.

Le poste qu’on sous-estime : la reprise des données

Ce n’est pas la configuration qui fait déraper un projet d’ERP, c’est ce qui existait avant. Un fichier client tenu dans un tableur depuis huit ans, des doublons, des adresses obsolètes, un historique de facturation dans un logiciel qu’on ne peut plus ouvrir.

Nous traitons ce sujet en premier, parce qu’il conditionne le reste : qu’est-ce qui doit être repris, qu’est-ce qui doit être archivé sans être repris, et qu’est-ce qui doit être nettoyé avant. Quand il n’existe pas d’export exploitable, nous écrivons le programme qui va chercher les données — c’est une pratique courante, pas une exception.

Le brancher sur ce que vous avez déjà

Un ERP n’a d’intérêt que s’il devient la référence. Il se relie donc à votre site ou à votre boutique en ligne, à un extranet où vos clients suivent leurs commandes, à un intranet qui affiche les données sans en garder une copie qui deviendrait fausse, et à votre chaîne de facturation.

La règle que nous appliquons est simple : une donnée fait foi à un seul endroit, les autres systèmes la lisent. C’est ce qui évite les trois fichiers clients qui divergent.