Il est facile de mal trancher entre développer et acheter une solution d’IA.
D’un côté, on vous recommande : « Achetez simplement l’outil. Les éditeurs ont déjà résolu ce problème. » De l’autre : « Nous avons besoin d’une IA personnalisée. Notre flux de travail est particulier. » Ces deux positions peuvent être justes. Elles s’avèrent toutes deux coûteuses lorsqu’elles sont appliquées avec négligence.
La décision ne se résume pas à l’alternative entre développement et achat. Elle consiste généralement à :
- Acheter un outil.
- Configurer un outil existant.
- Étendre un outil par l’automatisation des flux de travail.
- Développer un système sur mesure autour d’API de modèles d’IA.
- Auto-héberger ou affiner un modèle uniquement si des éléments solides le justifient.
Cet article propose un cadre pratique.
Évaluez l’ensemble du système : accès aux données, adéquation au flux de travail, validation, autorisations, intégrations, surveillance, revue humaine, opérations, conditions contractuelles et coût de sortie. Ne prenez pas votre décision sur la base d’une démonstration de modèle.
Commencez par le type de capacité
| Capacité | Hypothèse initiale | Pourquoi tester cette option |
|---|---|---|
| Rédaction générique, assistance aux réunions, recherche, aide à la programmation | Tester d’abord l’achat ou la configuration | Plusieurs solutions peuvent satisfaire une exigence bien délimitée |
| Flux de travail courant en entreprise | Tester d’abord l’achat ou la configuration | Les systèmes déjà utilisés par l’entreprise proposent peut-être une fonction adaptée et gouvernée |
| Automatisation propre à un flux de travail | Comparer l’extension et le développement | Les plateformes d’automatisation peuvent convenir, sous réserve de tests portant sur les contrôles, la fiabilité et l’intégration |
| Assistant exploitant les connaissances de l’entreprise | Configurer ou développer | Le choix dépend des autorisations et des sources |
| Agent en contact avec les clients | Développer ou étendre avec prudence | La marque, la sécurité, les intégrations et les journaux sont déterminants |
| Aide à la décision dans un domaine réglementé | Commencer par une revue qualifiée ; comparer une solution sectorielle approuvée, l’achat, le développement et l’absence d’IA | Le droit, les éléments probants, la responsabilité et la supervision peuvent exclure toute architecture |
| Différenciation au cœur du produit | Comparer les niveaux de maîtrise du système | Seules les données clients et opérationnelles permettent d’établir si cette maîtrise crée réellement un avantage |
Si plusieurs éditeurs satisfont aux exigences, l’achat peut réduire les responsabilités à assumer. Si le flux de travail est stratégique ou si les lacunes des éditeurs sont importantes, l’extension ou le développement sur mesure peut se justifier. Dans les deux cas, étayez l’affirmation par des preuves.
Les quatre dimensions décisionnelles
1. Adéquation au flux de travail
L’outil de l’éditeur correspond-il au processus réel ?
Posez-vous les questions suivantes :
- Peut-il accéder aux systèmes qui font autorité ?
- Peut-il appliquer nos règles d’approbation ?
- Peut-il gérer les exceptions ?
- Peut-il préserver les journaux d’audit ?
- Peut-il prendre en charge nos langues et les attentes des clients ?
- Les utilisateurs peuvent-ils travailler là où ils travaillent déjà ?
Si l’outil oblige l’équipe à contourner ses contraintes au quotidien, le prix d’achat est trompeur.
2. Contrôle des données
Quelles données entrent dans le système et où vont-elles ?
L’achat est plus simple lorsque les données sont publiques, internes ou déjà approuvées pour cet éditeur. Le développement sur mesure ou un déploiement privé devient plus probable lorsque les données sont confidentielles, réglementées, propres à un client ou soumises à des exigences strictes de localisation et de conservation.
Ne développez pas un système sur mesure pour donner une simple impression de confidentialité. Ne développez ou ne déployez une solution privée que lorsque les règles relatives aux données l’exigent réellement.
3. Profondeur d’intégration
Certains systèmes d’IA créent de la valeur grâce à des connexions gouvernées vers des systèmes de référence ou d’action : CRM, e-mail, calendrier, gestion des tickets, ERP, dépôts de documents, bases de données, paiements, identité et journaux. D’autres cas d’utilisation doivent rester isolés ou en lecture seule.
Comme hypothèse de départ, les intégrations standard peuvent favoriser l’achat, tandis que les flux de travail personnalisés et avec état peuvent favoriser l’extension ou le développement. Un essai représentatif doit tester les autorisations, la reprise après incident, l’observabilité et le coût de sortie.
Exemple :
- « Résumer les demandes d’assistance » → acheter ou configurer.
- « Trier les demandes d’assistance, vérifier le SLA du contrat, examiner la télémétrie du produit, rédiger une réponse, acheminer selon le niveau de service du client et journaliser toutes les décisions » → étendre ou développer.
4. Différenciation stratégique
Si des concurrents peuvent obtenir et configurer la même capacité avec des résultats comparables, cette seule capacité peut ne pas constituer un avantage durable. Mesurez la valeur pour le client et la différenciation opérationnelle plutôt que d’inventer un délai de copie.
Développez le système là où il formalise vos processus, vos données, votre distribution, votre expertise sectorielle ou l’expérience client d’une manière qu’un éditeur généraliste ne peut pas reproduire.
Coût total de possession
Comparez le coût complet, et non seulement la licence par rapport au temps des développeurs.
| Poste de coût | Achat | Développement |
|---|---|---|
| Licence/API | Contractuelle mais potentiellement variable selon les sièges, l’utilisation, le niveau ou les dépassements | API, inférence, infrastructure et services tiers |
| Mise en œuvre | Configuration, migration, intégration et gestion du changement | Travail de produit, d’intégration, de plateforme et de migration |
| Maintenance | L’éditeur assume certaines couches de la plateforme ; le client reste responsable de la configuration et des intégrations | Votre équipe assume les couches définies du système et leurs dépendances |
| Revue de sécurité | Vérifications préalables sur l’éditeur | Revue de l’architecture et du code |
| Intégration | Limitée par l’éditeur | Flexible mais coûteuse |
| Contrôle des changements | Risque lié à la feuille de route de l’éditeur | Charge liée à votre propre feuille de route interne |
| Assistance | Assistance de l’éditeur | Assistance interne |
| Coût de sortie | Limites d’extraction et d’exportation des données | Dette technique et responsabilités internes |
Chaque option peut entraîner des coûts importants et durables. Comparez, sur une même période, les devis à jour, le coût complet du travail, la migration, l’assistance, les incidents et les scénarios de sortie.
La grille d’évaluation
Attribuez une note à chaque dimension de 1 à 5, définissez la signification de chaque score, et pondérez les dimensions avant d’évaluer les éditeurs. Ne laissez pas un score total élevé annuler un veto lié à la sécurité, au droit, à la confidentialité, à la sécurité des personnes, à l’accessibilité ou à la localisation des données.
| Dimension | L’achat est favorisé lorsque le niveau est faible | Le développement est favorisé lorsque le niveau est élevé |
|---|---|---|
| Spécificité du flux de travail | Flux générique | Flux unique |
| Sensibilité des données | Publiques/internes | Confidentielles/restreintes |
| Profondeur d’intégration | Intégrations standard | Flux multi-systèmes personnalisé |
| Différenciation | Fonction banalisée | Avantage stratégique |
| Taux de changement | Feuille de route éditeur acceptable | Besoin d’itérations internes rapides |
| Capacité opérationnelle | Capacité d’ingénierie faible ou nulle | L’équipe peut assumer le système en production |
La grille d’évaluation associée à cet article fournit un modèle réutilisable. Joignez un élément probant à chaque note : résultat d’essai, clause contractuelle, revue d’architecture, devis, test de référence ou étude client.
Pour les solutions finalistes, mettez en œuvre le même périmètre représentatif et consignez la réussite des tâches, la reprise après incident, l’effort humain, la latence, le coût, les limites d’intégration, le comportement des autorisations, l’observabilité et le parcours d’extraction ou de sortie. Recalculez la note après l’essai.
Un arbre décisionnel pratique
- Un outil du marché répond-il en toute sécurité aux exigences obligatoires ? Testez les solutions à acheter ou à configurer.
- L’écart restant a-t-il une importance opérationnelle ? Étendez l’outil par automatisation avant de développer une solution sur mesure.
- Le flux de travail exige-t-il des données privées, des autorisations personnalisées ou une intégration poussée ? Comparez aux exigences obligatoires la configuration d’entreprise, une extension, une fine couche sur mesure et des contrôles manuels ou sans IA.
- Le comportement du modèle lui-même doit-il être personnalisé ? N’envisagez l’affinage qu’après avoir évalué des solutions plus simples et applicables, comme la formulation des prompts, la logique déterministe, la recherche documentaire ou les sorties contraintes. Évaluez chaque option.
- Le déploiement exige-t-il une maîtrise privée ? Envisagez un VPC ou l’auto-hébergement après avoir mesuré la qualité, le coût et la charge d’exploitation.
Commencez par le haut de l’arbre. Ne passez pas directement à une infrastructure sur mesure simplement parce que la démonstration paraît stratégique.
Quand acheter est le bon choix
Achetez lorsque :
- Le flux de travail est courant.
- L’éditeur s’intègre déjà à votre pile technique.
- La sensibilité des données est gérable.
- Le coût correspond à l’utilisation.
- Le délai d’obtention de la valeur est déterminant.
- La fonctionnalité ne constitue pas un facteur de différenciation.
- Vous ne disposez pas de la capacité pour exploiter un système personnalisé.
Exemples : synthèses de réunions, assistants de rédaction, macros simples pour l’assistance, autocomplétion de code, rédaction d’e-mails commerciaux, recherche interne dans des documents approuvés.
Quand développer est le bon choix
Développez lorsque :
- Le flux de travail est central pour l’entreprise.
- Les outils éditeurs ne peuvent pas appliquer les contrôles requis.
- Vous avez besoin d’une intégration profonde avec les systèmes internes.
- Les données ne doivent pas être envoyées à des SaaS génériques.
- Vous avez besoin d’une observabilité détaillée et d’évaluations approfondies.
- L’expérience utilisateur fait partie de votre produit.
- Vous pouvez le maintenir.
Exemples : produit d’IA destiné aux clients, flux documentaire réglementé, système RAG d’entreprise respectant les autorisations, agent sectoriel, pipeline d’extraction de données privées.
Ne faites pas cela pour l’instant
Ne développez pas une plateforme avant d’avoir validé un seul flux de travail.
N’achetez pas un outil sans revue du traitement des données.
N’acceptez pas les fonctionnalités IA des éditeurs sans tester des cas limites réels.
N’affinez pas un modèle avant d’avoir essayé la formulation des prompts, le RAG et les évaluations.
N’optez pas pour l’auto-hébergement simplement parce qu’il paraît privé. Démontrez l’exigence de confidentialité et votre capacité à exploiter le système.
Laissez l’essai représentatif trancher
Le bon choix entre développement et achat dépend des éléments probants propres au cas étudié. L’évaluation de la pertinence de l’IA proposée par le gouvernement britannique, dans sa version actuelle, commence elle aussi par déterminer si l’IA constitue une solution adaptée, en tenant compte des données, des utilisateurs, des préjudices possibles, des alternatives et du coût sur l’ensemble du cycle de vie.
Traitez l’achat, la configuration, l’extension, le développement sur mesure et les solutions manuelles ou sans IA comme des hypothèses. Parmi les options qui satisfont aux exigences obligatoires de flux de travail, de données, de sécurité, d’intégration, de coût, d’accessibilité et de réversibilité, choisissez celle qui impose le moins de responsabilités. Le modèle comme le système qui l’entoure peuvent être le facteur limitant ; un essai représentatif doit permettre de savoir lequel.
