Construire son outil interne plutôt que payer un abonnement

Pendant vingt ans, la réponse était évidente : on n’écrit pas son propre logiciel, on achète un abonnement. Le calcul a changé, parce que le coût de fabrication d’un outil sur mesure a été divisé dans des proportions que peu de dirigeants ont encore intégrées. Voici comment décider, sans basculer dans l’excès inverse.

Ce que le développement assisté a réellement changé

On entend parler de développement assisté par l’intelligence artificielle, parfois sous le nom de vibe coding. Derrière l’expression, la réalité est simple à décrire.

Un développeur expérimenté décrit en français ce qu’il veut obtenir, l’assistant écrit le code, le développeur le relit, le corrige, le teste et le met en service. Ce qui prenait des semaines prend des jours. Une interface de saisie, une chaîne de traitement de données, un petit outil métier avec ses écrans et ses contrôles : autant de choses dont la fabrication se comptait en dizaines de milliers d’euros et qui se comptent désormais en milliers.

Notez bien ce qui n’a pas changé. Il faut toujours quelqu’un qui sache lire du code, reconnaître une erreur, poser une architecture et mettre en production. L’assistant accélère un praticien, il ne remplace pas la compétence. Un dirigeant qui décrit son besoin à un assistant sans personne pour relire obtient une démonstration convaincante, puis découvre trois mois plus tard qu’elle ne résiste ni aux cas particuliers ni à la charge réelle.

Mais le déplacement de la frontière est considérable. Des besoins qui ne justifiaient pas un développement spécifique, et pour lesquels on s’accommodait donc d’un logiciel du marché mal adapté, le justifient aujourd’hui.

Les trois arguments en faveur du sur-mesure

Le coût de construction s’est effondré

Comparez sur trois ans. Un abonnement à trente euros par utilisateur et par mois, pour vingt utilisateurs, représente plus de vingt mille euros sur la période, et ce montant augmente à chaque révision tarifaire et à chaque nouveau collaborateur. Un outil interne construit pour un besoin précis se situe, pour une fonction délimitée, dans un ordre de grandeur comparable, sans loyer perpétuel ensuite. Le détail de cette comparaison, poste par poste, figure dans notre guide sur le coût réel de l’IA générative.

L’outil épouse le métier

C’est l’argument décisif, bien davantage que le prix.

Un logiciel du marché impose son vocabulaire, son découpage et ses étapes. Vos équipes passent une partie de leur temps à traduire leur métier dans le modèle de l’éditeur, à maintenir des tableurs parallèles pour ce que l’outil ne sait pas faire, et à contourner des champs obligatoires qui ne correspondent à rien chez vous. Ce coût-là ne figure sur aucune facture et il est souvent supérieur à l’abonnement.

Dans un cabinet d’études d’implantation d’une vingtaine de personnes, les chargés d’études préparent des études d’implantation, un travail qui suit une méthode propre au cabinet et qu’aucun logiciel du commerce ne connaît. Nous leur avons construit un outil de conception de ces études, directement utilisable par eux. Il ne fait qu’une chose, il la fait dans leurs termes, et il n’exige d’eux aucune traduction.

Ce point a une conséquence que l’on mesure mal tant qu’on ne l’a pas vécue. Un outil qui parle le langage de l’équipe ne demande presque pas d’accompagnement au changement. Il n’y a rien à déployer, rien à convaincre, pas de résistance à surmonter. Les utilisateurs l’adoptent parce qu’il leur fait gagner du temps dès la première utilisation, et non parce que la direction le leur a demandé.

La donnée reste chez vous

Un outil interne s’exécute dans votre infrastructure ou sur un hébergement que vous choisissez. Aucune base client ne part chez un éditeur tiers, la question de la région d’hébergement se règle en une décision, et le sujet des sous-traitants en cascade disparaît. Pour des données sensibles, cet argument pèse parfois plus lourd que les deux autres.

L’envers du décor, sans complaisance

Il faut maintenant dire pourquoi la sagesse populaire des vingt dernières années recommandait d’acheter plutôt que de construire. Elle avait de bonnes raisons, et elles n’ont pas toutes disparu.

Un outil interne meurt presque toujours de la même façon. Personne n’en assure la maintenance, parce que celui qui l’a fait est parti ou a changé de priorité. Il n’a pas de tests, donc la moindre modification casse quelque chose sans que personne le voie. Il n’a pas de surveillance, donc il tombe en panne un jeudi et l’on s’en aperçoit la semaine suivante. Et il repose sur un seul sachant, ce qui en fait une dépendance déguisée bien plus risquée qu’un abonnement.

Il faut y ajouter un cinquième symptôme, plus insidieux : l’outil qui grossit. Conçu pour une tâche, on lui ajoute une deuxième fonction, puis une troisième, jusqu’à ce qu’il devienne un logiciel de gestion complet que personne n’a jamais architecturé pour cela.

Ces risques sont réels. Ils sont aussi évitables, à condition de les traiter dès le premier jour plutôt que d’y penser après.

Comment un outil interne survit

Quatre exigences, et elles ne sont pas négociables si l’outil doit compter dans votre exploitation.

• Des tests automatiques sur le cœur des règles métier, exécutés à chaque modification.
• Une surveillance qui alerte quelqu’un de nommé quand un traitement échoue.
• Une documentation courte, orientée exploitation : comment ça tourne, où ça tourne, quoi faire en cas de panne.
• Au moins deux personnes capables d’intervenir, dont une qui n’a pas construit l’outil.

La surveillance mérite un développement, parce que c’est le point le plus souvent sacrifié. Chez le même client, des chaînes de traitement importent et contrôlent de grands référentiels publics, comme le répertoire des entreprises, les données de points d’intérêt et les données cartographiques ouvertes, puis les déposent dans l’entrepôt de données et dans les bases applicatives. Ces chaînes sont surveillées tous les mois, avec une alerte en cas d’anomalie.

Ce dispositif n’a rien d’impressionnant. Il n’a coûté qu’une fraction du temps de construction. Mais c’est lui qui permet de dire que ces chaînes fonctionnent, au lieu d’espérer qu’elles fonctionnent. Un outil interne surveillé est un actif. Un outil interne non surveillé est une dette qui s’ignore.

La question du sachant unique se règle, elle, par le mode de travail. Un outil construit dans vos dépôts, avec votre équipe associée à sa fabrication et une phase explicite de transfert, ne dépend pas de son auteur. C’est précisément l’objet de la troisième étape de notre méthode : installer la solution chez vous et vous en passer progressivement la main.

Quand acheter reste clairement le bon choix

Il serait absurde de conclure qu’il faut tout construire. Dans plusieurs situations, l’abonnement du marché reste la bonne décision, et nous le disons à nos clients.

Quand la fonction est standardisée et régie par des règles externes que vous ne maîtrisez pas. La paie, la comptabilité, la facturation électronique, la déclaration sociale : ces domaines changent au rythme de la réglementation, et un éditeur spécialisé absorbe ces changements pour vous. Les reconstruire serait une faute.

Quand le logiciel du marché est déjà un standard de votre écosystème, que vos partenaires et vos clients l’utilisent, et que l’interopérabilité vaut plus que l’ajustement au métier. C’est souvent le cas d’un outil de gestion de la relation client ou d’une suite bureautique.

Quand le besoin est instable et que vous ne savez pas encore ce que vous voulez. Commencez par un outil du marché, apprenez avec lui ce dont vous avez réellement besoin, et construisez plus tard si l’écart devient coûteux.

Quand, enfin, la fonction est vitale mais que vous n’avez aucune intention d’y consacrer une ligne de maintenance. Un outil interne sans mainteneur est plus dangereux qu’un abonnement mal adapté.

La bonne question n’est donc pas de savoir si l’on construit ou si l’on achète, mais de savoir où se trouve votre spécificité. Achetez ce que tout le monde fait de la même façon. Construisez ce qui fait votre différence, et qu’aucun éditeur ne modélisera jamais correctement parce que son marché est ailleurs.

Si vous entretenez aujourd’hui des tableurs parallèles pour compenser ce que vos logiciels ne savent pas faire, vous avez probablement déjà identifié le bon candidat. Un diagnostic sur le domaine concerné vous dira ce qu’il coûte de le construire, et ce qu’il vous fait gagner.