Développer, acheter ou intégrer l’IA ? Guide pour les entreprises de

Une entreprise de taille moyenne qui compare différentes options d’IA peut facilement comparer des éléments qui ne sont pas comparables. Un abonnement logiciel semble moins coûteux qu’un développement sur mesure, tandis qu’un prototype créé à l’aide d’une API semble plus rapide que l’un ou l’autre. Mais la bonne question n’est pas « Quelle technologie coûte le moins cher ? ». Elle est plutôt : « Quel modèle opérationnel offre à ce flux de travail le niveau adéquat d’adéquation, de contrôle, de rapidité et de réversibilité ? »

Pour un directeur général ou un CIO à Bruxelles, trois choix se présentent généralement. Acheter un produit prêt à l’emploi lorsque le processus est standard et que le fournisseur en couvre déjà la majeure partie. Développer lorsque le flux de travail crée une réelle différenciation ou nécessite des contrôles que les produits existants ne peuvent pas fournir. Intégrer lorsque les systèmes existants doivent rester les sources de référence et que l’IA doit coordonner le travail entre ceux-ci. De nombreuses mises en œuvre réussies sont hybrides : acheter un modèle ou une application, l’intégrer au flux de travail opérationnel et ne développer que la fine couche qui apporte une réelle différenciation.

Commencez par le flux de travail, pas par une liste de produits

Définissez un flux de travail unique, depuis son déclenchement jusqu’au résultat enregistré. Un flux de réponse aux clients pourrait commencer à l’arrivée d’un e-mail et se terminer lorsque le CRM contient une réponse approuvée, un responsable et la prochaine action à entreprendre. Un flux de traitement des anomalies de commande pourrait commencer par une incohérence dans un ERP et se terminer lorsqu’une personne approuve une résolution documentée. Identifiez les données d’entrée, les systèmes, les décisions, les transmissions, les exceptions et le responsable redevable.

Ce périmètre révèle ce que la solution d’IA doit réellement accomplir. Un assistant prêt à l’emploi peut être performant pour rédiger du texte, mais ne pas disposer des autorisations, de la terminologie multilingue, des objets ERP, des étapes d’approbation ou de la piste d’audit nécessaires aux opérations. À l’inverse, un modèle sur mesure constitue un gaspillage lorsqu’un produit mature fournit déjà la fonctionnalité nécessaire et que le processus peut s’y adapter.

Les trois options en pratique

Acheter : fonctionnalité standard et adoption rapide

L’achat est le choix le plus pertinent lorsque le processus est courant, que la configuration suffit et que la rapidité de création de valeur compte davantage que le caractère unique. Il peut notamment s’agir de la transcription de réunions, de l’extraction documentaire de base, de l’assistance générale à la productivité ou d’une fonctionnalité de support déjà intégrée au CRM de l’entreprise. Évaluez le produit complet plutôt que sa démonstration : localisation des données, conditions applicables aux sous-traitants, conservation, contrôles d’accès, formats d’exportation, journaux d’administration, limites de service, changements de modèles, support et assistance en cas de résiliation.

Le risque caché réside dans les compromis imposés au processus. Les équipes peuvent adapter un flux de travail critique aux hypothèses d’un fournisseur, créer des tâches manuelles entre les systèmes ou découvrir que les possibilités d’exportation et de suppression sont insuffisantes. Le règlement européen sur les données s’applique depuis le 12 septembre 2025 et comprend des règles visant à faciliter le changement de fournisseur de services de traitement de données. Cela renforce l’intérêt de tester la portabilité, mais ne remplace pas un plan de sortie concret, des exportations exploitables et des responsabilités contractuelles.

Développer : logique différenciante et contrôle approfondi

Le développement est approprié lorsque la connaissance exclusive du flux de travail est importante, que la logique décisionnelle est inhabituelle ou que les exigences de sécurité et de contrôle ne peuvent pas être satisfaites par des produits standard. « Développer » signifie rarement entraîner un modèle de fondation à partir de zéro. Il s’agit généralement d’assembler des modèles et une infrastructure existants au sein d’une application conçue sur mesure, avec les périmètres de données, le jeu d’évaluation, l’interface, les approbations et le suivi propres à l’entreprise.

Le coût de développement visible ne représente qu’une partie du coût de possession. Prenez également en compte la gestion du produit, la préparation des données, l’intégration, les tests, l’examen de sécurité, l’assistance aux utilisateurs, les changements de modèles, la réponse aux incidents et la maintenance lorsque les systèmes sources évoluent. Un système sur mesure sans responsable de produit désigné devient un prototype coûteux. Ne développez que lorsque l’adéquation supplémentaire ou la différenciation peut justifier cette obligation continue.

Intégrer : préserver les systèmes de référence et modifier le flux de travail

L’intégration constitue souvent la voie intermédiaire la plus pratique pour les entreprises belges et néerlandaises de taille moyenne. Le CRM, l’ERP, le référentiel documentaire ou la plateforme de gestion des tickets reste la source de référence. L’IA extrait, classe, recherche, recommande ou rédige ; une couche d’orchestration déplace les informations entre les systèmes et transmet les cas incertains à des personnes. Cette approche évite de remplacer une plateforme essentielle dans le seul but d’ajouter un flux de travail intelligent.

L’intégration n’est pas nécessairement simple. Chaque connecteur implique une authentification, une mise en correspondance des champs, des limites de débit, des changements de version, une journalisation, des nouvelles tentatives et une récupération après défaillance. Testez précisément les objets et les autorisations nécessaires plutôt que de considérer l’affirmation « il existe une API » comme une preuve suffisante. L’architecture doit préciser ce qui se passe lorsque le modèle, le connecteur ou le système source est indisponible.

Une grille décisionnelle à sept facteurs

Attribuez à chaque facteur une note de un à cinq, documentez les éléments probants et comparez les options sur la base des mêmes hypothèses.

Différenciation : Ce flux de travail crée-t-il un avantage ou s’agit-il d’une tâche administrative standard ? Les tâches standard favorisent l’achat ; une logique opérationnelle distinctive peut justifier un développement.
Sensibilité des données : Identifiez les données à caractère personnel, confidentielles, réglementées et transfrontalières. Une sensibilité accrue renforce l’importance de l’architecture, des contrats, du contrôle d’accès et de l’auditabilité.
Profondeur de l’intégration : Comptez les systèmes, les actions d’écriture, les objets personnalisés et les dépendances. Une intégration profonde favorise souvent une couche d’intégration contrôlée plutôt qu’un outil autonome.
Délai de création de valeur : Distinguez une démonstration rapide d’une solution prête pour la production. L’achat peut réduire le temps de mise en œuvre, mais uniquement si les achats, la sécurité, les données et l’adoption sont compatibles.
Capacité de prise en charge : Désignez les personnes qui exploiteront, évalueront, prendront en charge et amélioreront le système après son lancement. Si personne n’est responsable d’un produit sur mesure, ne le développez pas.
Exposition à la maintenance : Estimez les changements apportés aux modèles, aux prompts, aux intégrations, aux politiques et aux systèmes sources sur une période de trois ans, et pas uniquement le budget de lancement.
Coût de sortie : Testez l’exportation des données, la portabilité de la configuration, l’effort de remplacement, le préavis contractuel et la continuité si un fournisseur modifie ses prix ou ses fonctionnalités.

Utilisez la grille pour mettre en évidence les compromis, et non pour produire artificiellement une réponse précise. Une décision à haut risque concernant un client ou l’emploi peut nécessiter un contrôle humain renforcé, indépendamment de l’option obtenant la note la moins coûteuse. Un outil interne de synthèse à faible risque peut justifier une décision d’achat plus rapide.

Un processus de mise en œuvre pour Bruxelles et le Benelux

Cartographiez un segment de production. Dans le cadre d’ateliers réunissant les opérations, l’IT, la sécurité et le responsable du processus, consignez la situation de référence actuelle ainsi que les exceptions que les personnes traitent manuellement.
Classez les données et les décisions. Identifiez les données à caractère personnel, les dossiers confidentiels, les personnes concernées, les actions automatisées et les étapes où une intervention humaine est obligatoire. L’EDPB explique qu’une AIPD est requise lorsque le traitement est susceptible d’engendrer un risque élevé ; considérez cette évaluation comme une donnée d’entrée de l’architecture, et non comme une formalité administrative à accomplir après l’achat.
Présélectionnez les trois approches. Demandez aux fournisseurs de démontrer le flux de travail exact à l’aide de données de test représentatives. Estimez les options comparables de développement sur mesure et d’intégration avec les mêmes contrôles et la même période de support.
Vérifiez les rôles réglementaires. En vertu du règlement européen sur l’IA, les obligations dépendent du système et du rôle de l’organisation : fournisseur, déployeur, importateur ou distributeur. Les obligations en matière de maîtrise de l’IA s’appliquent depuis le 2 février 2025, tandis que la plupart des dispositions s’appliquent à partir du 2 août 2026, sous réserve de certaines exceptions. Consignez la classification et sollicitez un avis juridique lorsque l’incidence est significative.
Concevez le périmètre de contrôle. Définissez les autorisations, les seuils d’approbation, les comportements de refus et d’escalade, les journaux, la conservation, le suivi et le retour à une version antérieure. Pour les activités multilingues en Belgique, testez séparément des exemples en néerlandais, en français et en anglais ; ne présumez pas que les performances se transfèrent d’une langue à l’autre.
Menez un projet pilote mesuré en production. Faites intervenir de vrais utilisateurs et appliquez de véritables contrôles dans un périmètre restreint. Les pôles européens d’innovation numérique proposent des services « tester avant d’investir » et un accompagnement connexe qui peuvent aider les PME à évaluer une technologie avant de prendre un engagement plus large.
Approuvez avec un plan de sortie. Conservez l’architecture, les résultats des évaluations, les contrats, les responsabilités, les étapes d’exportation et les hypothèses de remplacement avec la décision d’investissement.

Contraintes qui doivent modifier la décision

Ne développez pas lorsque l’entreprise ne dispose pas d’une source de référence stable, d’un responsable ou de la capacité nécessaire pour assurer le support d’un logiciel. N’achetez pas lorsque le produit exige une utilisation inacceptable des données, offre de faibles possibilités d’exportation ou impose une conception de processus qui crée davantage de tâches manuelles. N’intégrez pas un processus fragile simplement parce que des API existent. Commencez par résoudre le manque de clarté des responsabilités, les doublons de données et les exceptions non maîtrisées.

Les achats doivent également distinguer le risque lié au modèle du risque lié au flux de travail. Un modèle fiable peut malgré tout produire un résultat préjudiciable si les autorisations, le contexte ou les actions en aval sont incorrects. À l’inverse, un modèle imparfait peut être utile s’il se limite à rédiger une recommandation qu’une personne formée doit approuver. Les contrôles doivent être proportionnés aux conséquences d’une défaillance.

Mesurer la valeur sans inventer des économies

Consignez une situation de référence avant de sélectionner une option. Mesurez le volume, le temps de traitement actif, le temps d’attente, les reprises, les taux d’erreur et d’exception, les escalades et le coût des retards. Choisissez un résultat principal, tel que le délai entre la demande et la résolution approuvée, ainsi que des garde-fous tels que le taux de correction, le taux de réponses non étayées, les violations de politiques ou les incidents.

Pendant le projet pilote, comparez l’achat, le développement et l’intégration à l’aide de la même grille : qualité des résultats, adoption par les utilisateurs, effort de mise en œuvre, coûts d’exploitation, charge de support, couverture des contrôles et récupération après défaillance. Procédez à un examen après plusieurs cycles opérationnels. Les heures « touchées » par l’automatisation ne correspondent pas automatiquement à des économies financières ; la valeur peut plutôt se manifester par des réponses plus rapides, une capacité accrue, moins d’erreurs ou une meilleure traçabilité. Toute extension doit reposer sur des éléments démontrant que le flux de travail s’est amélioré sans transférer des tâches cachées vers l’IT, la finance ou les opérations.

Intyb aide les entreprises de taille moyenne à transformer cette décision en un segment de production contrôlé grâce à des solutions d’IA sur mesure destinées aux organisations établies à Bruxelles et dans l’ensemble du Benelux. Consultez notre guide des coûts de mise en œuvre de l’IA afin d’établir des hypothèses comparables de coût de possession, ou discutez de votre flux de travail avec Intyb.

FAQ

L’achat d’une solution d’IA est-il toujours moins coûteux que son développement ?

Non. L’achat réduit généralement l’effort de développement initial, mais les licences, le travail d’intégration, les compromis imposés au processus, le support et les coûts de sortie doivent être inclus dans la comparaison. Une vision du coût de possession sur trois ans est plus utile que le seul prix de l’abonnement.

Quand l’intégration est-elle préférable au remplacement ?

L’intégration est particulièrement pertinente lorsque les systèmes CRM, ERP, documentaires ou de gestion des tickets existants restent des sources de référence fiables et que l’IA doit améliorer un flux de travail qui les traverse. Elle permet d’éviter le remplacement d’une plateforme essentielle tout en préservant les approbations et les enregistrements.

Une entreprise belge doit-elle réaliser une AIPD pour chaque projet d’IA ?

Pas automatiquement. En vertu du RGPD, une AIPD est requise lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Évaluez le cas d’usage dès le début, documentez la décision et faites intervenir des spécialistes de la protection de la vie privée lorsque des données à caractère personnel ou des décisions lourdes de conséquences sont concernées.

Que doit démontrer un projet pilote avant un déploiement plus large ?

Il doit démontrer le résultat opérationnel, la conception des contrôles, l’adoption par les utilisateurs, le traitement des exceptions, la charge de support et la capacité de récupération à l’aide de données représentatives. Il doit également permettre de désigner un responsable et de produire une comparaison avec la situation de référence, une procédure opérationnelle et une voie de sortie crédible.