Il y a dix ans, la question “make or buy” se résumait souvent à un calcul simple : est-ce qu’on a les devs pour le faire ? Aujourd’hui, avec l’IA agentique qui accélère les développements et standardise les pratiques, l’équation mérite d’être revisitée.
Non pas que la réponse soit devenue plus simple. Elle reste “it depends”. Mais les critères sur lesquels ça dépend ont évolué.
Vue d’ensemble du framework de décision
Les mythes qui font prendre de mauvaises décisions
Commençons par évacuer les réflexes qui mènent dans le mur — des deux côtés.
Côté Buy
Attention
Mythe : “Acheter, c’est plus rapide.”
C’est rarement vrai. Une intégration Salesforce ou SAP, c’est 12 à 18 mois dans le meilleur des cas. Ajoutez les customisations “indispensables”, les reprises de données, la conduite du changement. Pendant ce temps, une équipe interne bien cadrée aurait pu livrer un outil ciblé et opérationnel.
Attention
Mythe : “SaaS = pas de maintenance.”
Le SaaS déplace la maintenance, il ne la supprime pas. Les intégrations avec votre SI, les workflows spécifiques, les évolutions demandées par le métier — tout ça reste à votre charge. Et quand l’éditeur décide de déprécier une fonctionnalité que vous utilisez, c’est votre problème.
Côté Make
Attention
Mythe : “On n’a pas les compétences, donc on ne peut pas.”
C’est confondre un état et une fatalité. Une compétence, ça se construit : recrutement, formation, accompagnement externe. La question n’est pas “est-ce qu’on sait faire ?” mais “combien ça coûte de savoir faire, et est-ce que ça vaut le coup ?”.
Attention
Mythe : “On peut le faire en deux semaines.”
Le syndrome du POC qui devient produit. Oui, on peut prototyper vite. Mais un logiciel en production, c’est aussi la gestion des cas limites, la documentation, le support, les évolutions, la sécurité. Deux semaines deviennent six mois, puis deux ans de maintenance.
Attention
Mythe : “Si c’est pas nous qui l’avons codé, c’est pas bien.”
Le syndrome NIH — Not Invented Here. Recoder un système d’authentification, un moteur de workflow ou un bus de messages parce qu’on veut “maîtriser”… c’est souvent de l’énergie gaspillée. Des projets open source comme Keycloak ont des années d’avance et des centaines de contributeurs. Sauf cas exceptionnel, on ne recode pas Keycloak.
La vraie question : où est votre avantage concurrentiel ?
Avant de parler technologie, budget ou planning, il y a une question à trancher : est-ce que ce qu’on construit nous différencie du marché ?
C’est la ligne de partage fondamentale.
Ce qui relève du “core” — là où se situe votre avantage concurrentiel — mérite qu’on investisse pour le maîtriser. Utiliser le même outil que tout le monde, c’est au mieux être au niveau du marché. Pour faire mieux, il faut des outils qui reflètent vos spécificités.
Ce qui relève du “commodity” — ce que tout le monde fait de la même façon — ne justifie pas de réinventer la roue. La paie, la gestion des congés, l’authentification : sauf cas très particulier, ce n’est pas là que vous ferez la différence.
Un exemple concret
Prenez deux acteurs du retail. Le premier a construit son avantage sur le sourcing : dénicher les bons produits, les bons fournisseurs, avant les autres. Le second mise tout sur l’exécution de sa supply chain : livrer plus vite, moins cher, avec moins d’erreurs.
Pour le premier, le système de gestion des achats et de la relation fournisseurs est stratégique. Ça vaut le coup de construire du spécifique.
Pour le second, c’est l’outil de pilotage logistique qui mérite l’investissement. Le reste peut être standardisé.
Conseil
Le spectre des options
Make or Buy, c’est un faux dilemme. En réalité, vous avez un continuum d’options, chacune avec son équilibre entre contrôle et charge.
Côté Make
Make interne pur. Vos équipes conçoivent et développent. Vous maîtrisez tout : le code, l’architecture, la roadmap. C’est le maximum de contrôle — et le maximum de responsabilité. Vous portez le coût complet : développement, maintenance, évolutions, support.
Make avec prestataire. Vous faites construire du spécifique par une ESN ou des freelances, mais vous restez propriétaire. Le code est à vous, la dette technique aussi. Vous externalisez l’exécution, pas la responsabilité.
Make sur fondation open source. Vous partez d’une base existante — un framework, une brique technique — et vous construisez par-dessus. Vous bénéficiez du travail de la communauté pour les fondations, vous investissez sur ce qui vous différencie.
Côté Operate
C’est la troisième voie, souvent oubliée dans le débat.
Open source opéré en interne. Vous déployez une solution mature — Keycloak, Kafka, PostgreSQL — et vous la maintenez. Pas de licence, pas de vendor lock-in. En échange, vous devez construire la compétence pour l’opérer : monitoring, mises à jour, sécurité, scaling.
Open source managé. Vous utilisez la même brique, mais un tiers l’opère pour vous. RedHat pour Keycloak, Confluent pour Kafka, votre cloud provider pour PostgreSQL managé. Vous payez pour ne pas porter la charge opérationnelle, tout en gardant une relative indépendance vis-à-vis d’un éditeur propriétaire.
Côté Buy
Licence + intégration. Vous achetez une brique logicielle et vous construisez autour. C’est le modèle historique : un ERP, un CRM, un WMS qu’on installe et qu’on intègre à son SI. Vous avez accès au produit, vous pouvez le customiser, mais vous dépendez de l’éditeur pour les évolutions et le support.
Solution éditeur customisable. On-premise, cloud privé, ou SaaS extensible. L’éditeur fournit une plateforme que vous adaptez à vos besoins. Plus de flexibilité qu’un SaaS pur, mais aussi plus de travail d’intégration. Et toujours la question : que se passe-t-il si l’éditeur change de stratégie ?
SaaS pur. Vous prenez le produit tel quel. Vous vous adaptez à ses contraintes, ses workflows, son modèle de données. C’est le minimum de charge — et le minimum de contrôle. Si le produit ne fait pas ce que vous voulez, vous avez deux options : changer votre processus ou changer de produit.
Le curseur
Ce n’est pas une question de mieux ou de pire. C’est un curseur.
Plus vous allez vers le Make pur, plus vous avez de contrôle sur votre destin. Vous décidez de tout. Mais vous portez tout : les coûts, les risques, la complexité.
Plus vous allez vers le SaaS pur, moins vous avez de charge au quotidien. Quelqu’un d’autre gère l’infrastructure, les mises à jour, la sécurité. Mais vous êtes locataire, pas propriétaire. Vos marges de manœuvre dépendent du bon vouloir de l’éditeur.
L’enjeu, c’est de positionner le curseur au bon endroit pour chaque besoin. Et ce bon endroit dépend d’un critère simple : est-ce que ce besoin est au cœur de votre avantage concurrentiel ?
Les critères qui comptent vraiment
L’expertise fonctionnelle : le vrai goulot d’étranglement
On parle souvent des compétences techniques. Rarement du vrai facteur limitant : l’expertise métier.
Vous pouvez avoir la meilleure équipe de développement du marché. Si le métier n’est pas disponible pour spécifier, challenger, valider — votre Make va produire un outil à côté de la plaque. Et aucune IA agentique ne compense une connaissance métier absente.
Info
Deux questions à se poser :
- L’expertise fonctionnelle existe-t-elle en interne ?
- Est-elle réellement mobilisable ?
Le second point est souvent sous-estimé. Une expertise qui existe mais n’est disponible que 30 minutes tous les 6 mois, c’est presque pire que pas d’expertise du tout. Vous pensez l’avoir, vous lancez le projet, et vous découvrez trop tard que personne n’est là pour arbitrer.
À noter : ce critère joue aussi pour le Buy. Sans disponibilité métier, votre intégration SaaS va dériver de la même façon. Mais le SaaS a au moins un “chemin par défaut” qui limite la casse.
La troisième voie : l’open source
Le débat Make or Buy occulte souvent une option intermédiaire : opérer une solution open source.
Keycloak pour l’IAM. Kubernetes pour l’orchestration. PostgreSQL pour la base de données. Ces projets ont atteint une maturité telle qu’ils sont devenus des standards de facto.
Opérer de l’open source, ce n’est ni du Make ni du Buy. Vous ne partez pas de zéro, mais vous gardez la main. Pas de licence à plusieurs millions, pas de vendor lock-in, et une communauté qui fait évoluer le produit.
Le coût ? La capacité à opérer. Ce qui nous amène au critère suivant.
Budget et souveraineté
Avoir du budget, ce n’est pas “acheter pour acheter”. C’est se donner le choix.
Plus vous avez de marge de manœuvre financière, plus vous pouvez décider de votre niveau de dépendance envers un éditeur. Construire une équipe capable d’opérer du Keycloak plutôt que de signer Okta à plusieurs centaines de milliers d’euros par an, c’est un investissement en souveraineté.
À l’inverse, un budget contraint force parfois des arbitrages douloureux. On achète parce qu’on n’a pas les moyens de construire la capacité interne. Ce n’est pas un mauvais choix — c’est un choix contraint qu’il faut assumer comme tel.
Danger
Le vrai risque : l’angle mort de la dépendance.
Cas vécu : un retailer dont une brique centrale de la supply chain reposait sur un éditeur. Des centaines de milliers d’euros investis en intégration et customisation. Un jour, l’éditeur annonce qu’il arrête le produit. Bonne chance.
Le temps — des deux côtés
“On n’a pas le temps, donc on achète.”
C’est souvent un raccourci dangereux. Le temps joue des deux côtés.
Une intégration SaaS ou éditeur ne se fait jamais sans douleur. Compter 12 à 18 mois pour un projet d’envergure, sans garantie de succès. Pendant ce temps, une équipe interne avec la bonne expertise fonctionnelle peut livrer un premier jet ciblé en quelques mois.
Là où le temps devient vraiment critique, c’est dans les situations d’urgence stratégique. Un concurrent qui investit votre marché, une opportunité à saisir vite. Dans ce cas, la question devient : qu’est-ce qui me donne un avantage compétitif le plus rapidement ?
Si l’expertise fonctionnelle est disponible : Make ciblé, vite.
Si elle ne l’est pas : Buy pour aller vite, mais avec une stratégie de reprise de contrôle. On achète du temps, pas une solution définitive.
La grille de décision
Voici les questions à se poser, dans l’ordre.
1. Est-ce un avantage concurrentiel ?
Si oui, la maîtrise compte. Orientez-vous vers le Make ou l’Operate. Si non, pas besoin de réinventer la roue — le Buy ou l’OSS managé peuvent suffire.
2. L’expertise fonctionnelle est-elle disponible ?
Pas “existe-t-elle quelque part dans l’entreprise”. Est-elle mobilisable, maintenant, pour ce projet ? Si oui, le Make devient viable. Si non, soit vous investissez pour la rendre disponible, soit vous partez sur du Buy avec un chemin par défaut qui limite les dégâts.
3. Existe-t-il une solution open source mature ?
Pour l’IAM, l’orchestration, les bases de données, le messaging — la réponse est souvent oui. Dans ce cas, la question devient : opérer en interne ou passer par du managé ? Le choix dépend de votre capacité à construire et maintenir cette compétence.
4. Quelle est l’urgence stratégique ?
Si vous avez le temps, vous pouvez construire la capacité qui vous manque. Si un concurrent investit votre marché demain, vous n’avez peut-être pas ce luxe. Dans ce cas, achetez du temps — mais avec une stratégie de reprise de contrôle.
5. Quel est votre budget réel ?
Pas le budget projet. Le budget qui inclut la maintenance sur 5 ans, les évolutions, les coûts cachés. Et surtout : avez-vous le budget pour choisir, ou êtes-vous contraint de subir ?
6. Quel niveau de dépendance acceptez-vous ?
C’est la question de la souveraineté. Un éditeur peut changer ses tarifs, déprécier une fonctionnalité, arrêter un produit. Êtes-vous prêt à porter ce risque ? Avez-vous un plan B ?
En synthèse
| Critère | Oriente vers Make/Operate | Oriente vers Buy |
|---|---|---|
| Avantage concurrentiel | Oui | Non |
| Expertise fonctionnelle dispo | Oui | Non ou faible |
| OSS mature disponible | Operate | Buy si pas d’OSS |
| Urgence stratégique | Make si expertise dispo | Buy + exit strategy |
| Budget suffisant | Liberté de choix | Choix contraint |
| Tolérance à la dépendance | Faible → Make/Operate | Acceptable → Buy |
Ce n’est pas un algorithme. C’est une grille de lecture pour structurer la discussion et challenger les réflexes.
Conclusion
La réponse est toujours “it depends”. Mais maintenant, vous savez sur quoi.
L’IA agentique change l’équation — pas seulement parce qu’on code plus vite, mais parce qu’on peut standardiser les pratiques, partager des blueprints, industrialiser ce qui était artisanal. Le Make n’a jamais été aussi accessible.
Pour autant, ce n’est pas une raison pour tout reconstruire. Le vrai travail, c’est d’identifier ce qui vous différencie vraiment. De regarder honnêtement si l’expertise métier est là — et disponible. D’évaluer votre tolérance à la dépendance. D’assumer vos choix, y compris quand ils sont contraints.
Un DSI qui a traversé ces questions peut défendre sa stratégie devant n’importe quel board. Pas avec des certitudes, mais avec une méthode. Et face à un choix technologique, c’est souvent la seule chose qui compte.
Commentaires
💬 Les commentaires sont partagés entre toutes les versions linguistiques de cet article.