La question que presque toutes les entreprises posent à l'envers
J'ai passé une bonne partie d'une décennie du mauvais côté de cette question.
Pendant sept ans, dans mon entreprise précédente, développer les logiciels métier de la maison était mon travail. Pas un projet parallèle, pas une initiative trimestrielle — c'était ce que je faisais tous les jours, avec ce travail plus ingrat et plus silencieux qui consiste à s'assurer que les gens se servent vraiment de ce qu'on leur livre. Aujourd'hui je dirige AgentUI, où j'aide d'autres entreprises à trancher exactement cette question. Alors quand on me demande s'il faut développer ou acheter, je ne vais pas chercher un cadre méthodologique lu quelque part. Je vais chercher des cicatrices.
Voici la version courte de ce que j'ai appris : la plupart des entreprises posent la question à l'envers. Elles commencent par « est-ce qu'on peut acheter ça ? » alors que la bonne question de départ est « est-ce que ce processus nous est propre ? » Ce ne sont pas les mêmes questions, et les confondre coûte des années.
Je m'explique.
Le réflexe par défaut, et pourquoi il est mauvais
La sagesse habituelle se tient plutôt bien sur le papier : essayez d'abord un logiciel standard, et ne développez que si rien ne convient. Nous avons suivi cette règle à la lettre. Nous cherchions toujours à acheter avant de développer.
Le problème, c'est ce que « essayer » voulait dire concrètement. Pour une partie critique de nos opérations, nous avons passé des années — pas des semaines, des années — à tenter de faire fonctionner un logiciel acheté. Nous avons utilisé deux outils différents sur cette période. Les deux ont échoué. Et ils ont échoué pour la même raison à chaque fois : ils nous demandaient d'adapter nos opérations à leur logiciel, au lieu d'adapter le logiciel à nos opérations.
Cette phrase, c'est tout le débat en miniature. Quand vous achetez un logiciel standard pour un processus réellement propre à votre entreprise, vous n'achetez pas une solution. Vous achetez un chantier de rénovation de votre façon de travailler tout entière, et la rénovation ne se termine jamais vraiment. Chaque contournement, chaque « bon, cette partie-là on la fera dans un fichier Excel à côté », chaque session de formation pour expliquer pourquoi l'outil ne fait pas la chose évidente — c'est le prix à payer pour forcer votre entreprise à entrer dans les hypothèses de quelqu'un d'autre.
Ce que personne ne vous dit, c'est que ce coût-là n'apparaît pas sur la facture. Le logiciel a un prix. Les années de frottement opérationnel, non.
Un cas concret : l'outil commercial qui nous a ouvert le monde
Rendons ça concret, parce qu'on approuve facilement une idée abstraite et qu'on en fait rarement quelque chose.
L'un des plus gros outils que j'ai construits était destiné à nos commerciaux. Avant lui, préparer un devis relevait de l'épreuve manuelle. Un commercial devait assembler une poignée de fichiers Excel, aller chercher des données de stock plus ou moins à jour, et retrouver l'information technique — les fiches techniques, les PDF, la documentation de mise en œuvre — là où elle se trouvait. C'était lent, source d'erreurs, et entièrement dépendant du fait que le commercial sache où était rangée chaque chose.
Nous avons donc construit un outil où un commercial se connecte, consulte le stock en temps réel et crée un devis à la demande. Le gain n'était pas seulement la vitesse. C'était que chaque information technique vivait au même endroit. Vous cliquiez sur un produit et vous voyiez tout : les spécifications, la documentation, les PDF, la mise en œuvre. Et ensuite — c'était la partie qui comptait le plus — vous pouviez partager l'ensemble avec un client en un seul clic.
Cet outil a produit un effet que je n'avais pas complètement anticipé en commençant. Il nous a permis de gagner des clients partout dans le monde, des clients que nous n'avions jamais pu atteindre auparavant. Quand un prospect sur un autre continent reçoit un devis complet, professionnel et techniquement détaillé en quelques minutes au lieu de plusieurs jours, la géographie cesse de compter. L'outil ne nous a pas seulement rendus plus rapides. Il a agrandi le marché que nous pouvions sérieusement servir.
Aucun produit standard n'allait jamais faire ça, parce qu'aucun produit standard ne comprenait notre stock, notre documentation technique et notre façon de vendre comme nous les comprenions. Nous avons essayé. Vous vous souvenez de ces deux outils et de ces années perdues ? C'est ça qu'ils tentaient de remplacer, sans y arriver.
Alors, quand faut-il acheter ?
Si vous êtes arrivé jusqu'ici en pensant que je suis un intégriste du « développez tout vous-même », laissez-moi corriger ça tout de suite. Je ne le suis pas.
Je ne développerais jamais un CRM. Notre CRM, nous l'achetons, point final, et je conseillerais à presque tout le monde d'en faire autant.
Voici la nuance. Un CRM doit s'intégrer à votre messagerie et à une douzaine d'autres outils. C'est une catégorie réellement complexe et mature, et les produits existants sont solides précisément parce que des milliers d'entreprises les ont éprouvés pendant des années. Il n'y a aucun avantage particulier à en fabriquer un à soi. Vous dépenseriez une énergie énorme pour arriver, au mieux, à quelque chose d'un peu moins bon que ce que vous auriez pu acheter dès le premier jour.
C'est ça le test, et il est plus simple que la plupart des cadres « développer ou acheter » :
- Achetez quand le problème est universel. Si cent autres entreprises ont le même besoin que vous, quelqu'un en a déjà fait une meilleure version que la vôtre, et l'a déjà intégrée à tout le reste. CRM, messagerie, comptabilité, paie — ces sujets sont réglés. Ne les réinventez pas.
- Développez quand le processus vous est propre. Quand vous avez une façon de travailler spécifique à la manière dont votre entreprise fonctionne — comme nous avec nos devis techniques — c'est exactement le moment où développer a du sens. Aucun produit ne convient, parce que le processus n'existe qu'à l'intérieur de vos murs.
La question décisive n'est jamais « est-ce qu'un logiciel existe pour ça ? ». C'est « ce que je fais ici est-il assez différent pour qu'aucun logiciel générique ne puisse le capturer ? » Si oui, développez. Si non, achetez et passez à autre chose.
Ce que l'IA a réellement changé
Pendant l'essentiel de ma carrière, cet arbre de décision s'accompagnait d'un astérisque brutal : même quand développer était clairement le bon choix, c'était cher. Il fallait des développeurs. Il fallait du temps. L'option « développer » était juste en théorie et souvent hors de portée en pratique, ce qui explique pourquoi tant d'entreprises se rabattaient sur l'achat d'outils qui ne leur allaient pas — et en souffraient ensuite des années, comme nous.
L'IA a fait disparaître cet astérisque, et c'est la partie qui m'enthousiasme vraiment.
L'ancien monde vous obligeait à adapter toute votre organisation au logiciel. Le nouveau vous laisse construire un logiciel qui s'adapte à votre entreprise. Ce renversement, c'est tout l'enjeu. Chaque entreprise est unique, et pour la première fois vous pouvez avoir un système qui numérise vos opérations et la manière précise dont vous menez votre activité — sans armée d'ingénieurs pour le faire.
C'est exactement ce que nous construisons chez AgentUI. L'idée, c'est que vous puissiez créer avec l'IA le logiciel dont votre équipe a besoin, au lieu de recruter un développeur et d'attendre des mois. Soyons clairs : les développeurs ont toujours un métier. Pour un produit destiné à vos clients, je prendrais un développeur sans hésiter une seconde — ce que vos clients ont entre les mains mérite ce niveau de soin et de savoir-faire. Mais pour les logiciels internes ? Dans la plupart des cas, vous n'en avez plus besoin. Il vous faut de l'IA et un outil qui vous permette de construire.
Cela déplace le calcul « développer ou acheter » d'une façon qu'on sous-estime facilement. Quand développer coûtait cher, « acheter et plier ses opérations » était souvent le choix rationnel, même quand ça faisait mal. Maintenant que développer est rapide et peu coûteux, la balance penche fortement vers la construction de tout ce qui vous appartient vraiment.
Les deux objections que j'entends le plus
Chaque fois que je défends cette position, deux inquiétudes reviennent presque à coup sûr. Elles sont légitimes et méritent des réponses franches.
« Et la sécurité ? »
C'est la grande objection. Les entreprises craignent les fuites d'informations, les mauvaises personnes qui accèdent aux données, le piratage, la perte de données. La crainte est fondée : historiquement, développer ses propres logiciels revenait à hériter de ses propres problèmes de sécurité. C'est un point que nous traitons directement chez AgentUI avec une infrastructure infogérée, pour que tout ce que vous construisez soit sécurisé par défaut. Vous ne devriez pas avoir à devenir expert en sécurité pour créer un logiciel interne, ni à choisir entre « ça colle à notre activité » et « ça ne nous vaudra pas une fuite de données ».
« On va devoir le maintenir éternellement, non ? »
C'est la peur de la maintenance et de la dette technique, et c'est celle qui tue discrètement beaucoup de bonnes décisions. On suppose que développer, c'est signer pour une éternité d'entretien. Mais voici ce que l'on oublie : il arrive un moment où vous pouvez tout simplement arrêter de développer. L'outil fait son travail et vous vous en éloignez. Et la partie réellement difficile — maintenir l'infrastructure en dessous, celle qui provoque l'angoisse — c'est précisément ce dont nous nous occupons côté technique, pour que vous n'ayez pas à surveiller chaque morceau. Construisez-le, terminez-le, passez à la suite.
L'avis à contre-courant : arrêtez de vouloir bâtir une cathédrale
Voici l'opinion sur laquelle je plante mon drapeau, et c'est là que la plupart des gens se trompent, même une fois qu'ils ont décidé de développer.
N'essayez pas de construire un énorme système de zéro. C'est une mauvaise idée, presque toujours.
Le réflexe, quand une entreprise s'enthousiasme à l'idée de créer ses propres logiciels, c'est de voir gigantesque — d'architecturer une vaste plateforme maison qui fera tourner toute la société. C'est comme ça que les projets meurent. Ils s'effondrent sous leur propre ambition avant d'avoir livré la moindre valeur.
Le bien meilleur mouvement consiste à numériser les processus que vous faites déjà à la main — ceux qui vivent dans Excel en ce moment même, ceux qui sont propres à votre entreprise. C'est tout. Trouvez le fichier Excel que votre équipe redoute, l'assemblage manuel qui avale des heures chaque semaine, la chose que seule votre entreprise fait, à sa seule manière. Construisez ça. C'est petit, c'est concret, le bénéfice est évident, et c'est exactement le genre de chose qu'aucun logiciel standard ne traitera jamais bien.
Commencez par le fichier Excel douloureux, pas par la grande vision. La cathédrale peut attendre. L'outil de devis qui nous a ouvert le monde n'est pas parti d'une ambition démesurée — il est parti de « ce processus manuel nous épuise, réglons-le ».
En résumé
Achetez ce qui est universel. Construisez ce qui vous appartient vraiment. Ne pliez pas vos opérations à un logiciel qui n'a jamais été conçu pour vous — nous avons fait cette erreur pendant des années, et la facture est arrivée en temps perdu et en occasions manquées. Et quoi que vous construisiez, commencez petit, commencez par le processus manuel que vous connaissez déjà, et laissez l'outil grandir à partir de là.
Pendant l'essentiel de ma carrière, ce conseil venait avec la réserve que développer était un luxe. Ça ne l'est plus. Ce qui exigeait autrefois des développeurs et des trimestres de travail peut désormais être construit par les personnes qui comprennent réellement le processus — c'est-à-dire par vous.
C'est ça, le vrai basculement. La question n'a jamais été seulement développer ou acheter. Elle était de savoir si vous pouviez vous offrir un logiciel qui épouse votre façon de travailler. Maintenant, vous le pouvez.