Build VS Buy : construire en interne une solution de satisfaction client - avec ou sans IA - ou s’appuyer sur une plateforme déjà industrialisée ?

Avec le développement des outils IA, certaines enseignes sont tentées de développer en interne leur propre solution de pilotage de la satisfaction client.

La tentation du build repose sur une volonté de réduire sa dépendance économique. Elle s’appuie sur la promesse que l’IA peut tout gérer toute seule, moins cher et sans compétences techniques.

De prime abord, l’idée semble séduisante, mais elle est dangereuse.

Coder une application IA fonctionnelle et la passer à l’échelle avec l’IA sans compétences techniques reste largement un mythe. De plus, la valeur d’une solution de pilotage ne tient pas qu’à son code. D’autres paramètres sont à prendre en considération : robustesse, délivrabilité, qualité de la donnée à l’entrée et des insights à la sortie, adaptation métier, coût réel.

Oui, l’IA facilite le prototypage, mais la majorité des projets IA ne sont pas viables au-delà du POC. Au final, on arrive souvent à un POC qui ne passe pas la barre de l’industrialisation, sans compter des coûts qui se retrouvent bien supérieurs à ceux d’une solution clé en main.

L’illusion du “build facile” à l’ère de l’IA

Oui, l’IA peut accélérer le prototypage…

À première vue, l’IA rend le build beaucoup plus séduisant. Elle donne l’impression qu’il est désormais possible de prototyper vite, d’automatiser une partie du développement et de s’affranchir d’une équipe technique nombreuse.

Pour une enseigne, le build est synonyme de :

• Plus d’indépendance
• Une meilleure maîtrise des coûts
• Davantage de contrôle sur l’outil

Mais cette facilité apparente repose sur une illusion. Oui, l’IA accélère le prototypage ; non, elle ne transforme pas automatiquement un POC en logiciel métier robuste, industrialisé et durable.

… mais on ne peut pas tout coder avec l’IA

Une étude du MIT montre que, au-delà du POC, 95% des projets IA échouent ou ne créent aucun impact mesurable (Rapport MIT NANDA “State of AI in Business 2025).

Entre une démo qui fonctionne et une application fiable en production, il y a un écart important : architecture, gestion des droits, sécurité, qualité des données, supervision, intégrations externes, maintenance continue.

L’IA peut aider à écrire du code, mais elle ne supprime pas la complexité du produit. Une solution de pilotage de la satisfaction client ne se résume pas à une interface ou à quelques règles automatisées. Elle doit s’intégrer au système d’information, gérer des flux de données fiables, envoyer au bon moment, délivrer correctement, remonter des informations exploitables, rester conforme dans la durée.

La version finale du projet « build » devrait aussi intégrer toutes ces dimensions. Le build devient alors un projet complet, avec tous les sujets qu’un prototype ne traite pas forcément : connecteurs, calls API, cas limites, erreurs, charges, permissions, évolutions futures …

Même accéléré par l’IA, le build reste un projet transverse

L’IA peut réduire le nombre de personnes nécessaires pour « coder » un projet build. En pratique, une personne peut même travailler seule sur le sujet en déléguant une partie des tâches à l’IA.

Mais cette délégation présente des risques :

• Un défaut de prise en compte des implications du projet
• Une forte dépendance à la personne en charge : si cette personne quitte l’entreprise, la reprise devient difficile
• Un manque de documentation car les informations restent dans la "boîte noire" de l'IA

Par ailleurs, si l’IA accélère la partie applicative, elle ne supprime pas les tâches liées à la partie hosting/infrastructure et la compréhension et l’intégration des besoins métiers. En plus de la partie « codage », il faut encore prévoir les nombreux allers-retours avec les référents métiers.

Un projet de satisfaction retail ne se limite pas à coder une interface : il faut aussi recréer une partie du travail qu’un éditeur a déjà industrialisé sur les règles métier, la délivrabilité, les connecteurs et la mise en production.

Pourquoi les projets IA internes n’atteignent souvent pas l’industrialisation

Beaucoup de projets IA internes démarrent avec une promesse simple : un prototype rapide, une démonstration convaincante, puis une montée en charge progressive. Mais, en pratique, le point de rupture arrive souvent après le POC : le projet fonctionne “sur le papier”, mais ne passe pas la barre de l’industrialisation.

Un cadrage défaillant

Un POC peut être lancé avec une idée générale, mais une solution métier solide exige des objectifs précis, des règles fonctionnelles explicites, des critères de succès mesurables et des arbitrages clairs dès le départ.

Sans ce cadrage, le projet devient une usine à gaz. On ajoute des besoins en cours de route, on change les priorités. L’équipe passe plus de temps à réinterpréter le besoin qu’à construire une vraie solution.

Le budget et le time-to-value explosent, quand le projet n’est pas arrêté prématurément.

La dépendance à des collaborateurs clés

Le deuxième frein tient à la dépendance à une ou deux personnes. Dans beaucoup de projets internes, la connaissance reste concentrée sur un développeur, un chef de projet ou un référent métier, ce qui fragilise immédiatement la continuité du projet.

Dès qu’une personne est moins disponible, change de priorité ou quitte l’entreprise, le projet ralentit, se complexifie, ou nécessite une reprise coûteuse. Ce risque est particulièrement fort quand le projet est mené “en parallèle” des activités principales, avec un temps réellement consacré bien plus faible que ce qui avait été prévu.

La concurrence des urgences métiers

Dans une enseigne, un projet interne n’est jamais seul : il doit survivre aux demandes du quotidien, aux arbitrages budgétaires et aux imprévus opérationnels.

Développer un projet IA lié au pilotage de la satisfaction client est une chose. Mais si, en parallèle, l’équipe doit aussi développer une appli pricing et une solution supply chain, la disponibilité et la concentration se diluent, avec des périodes d’inertie qui allongent fortement les délais.

L’intégration au SI

À cela s’ajoute la difficulté d’intégration au système d’information. Un POC peut très bien fonctionner dans un environnement isolé, avec quelques données de test et un circuit simplifié. Mais une vraie solution métier doit se connecter au reste de l’écosystème : CRM, base client, outils d’envoi, SSO, reporting, permissions, règles RGPD, supervision et parfois d’autres briques internes. Plus l’intégration avance, plus le projet révèle sa vraie complexité. C’est souvent là que le “ça marche” du prototype cesse d’être suffisant.

Un défaut de gouvernance

Enfin, beaucoup de projets internes souffrent d’une gouvernance floue.

Qui arbitre les priorités ? Qui tranche en cas de dérive ? Qui porte le sujet au bon niveau ? Qui décide d’arrêter si le projet n’apporte pas assez de valeur ?

Sans sponsor clair, le projet, même s’il a été jugé prometteur au départ risque de rester bloqué au stade expérimental.

Les coûts cachés d’un projet IA en interne

Quand on compare les coûts d’un projet build à ceux d’un projet buy, on ne peut pas se contenter de regarder le coût initial. Au-delà des coûts de développement, il faut considérer le TCO (Total Cost of Ownership), c’est-à-dire le coût total de possession sur toute la durée de vie du projet.

Autrement dit, sur votre comparatif de coûts, il ne faut pas regarder seulement ce qu’il faut pour lancer une première version, mais tout ce qu’il faudra pour la faire fonctionner, l’intégrer, la sécuriser, la maintenir et l’améliorer dans le temps.

Ces dérives ne sont pas anecdotiques. Selon McKinsey Digital, « les grands projets IT dépassent en moyenne leur budget de 45 %, tout en délivrant 56 % de valeur en moins que prévu »¹.

C'est précisément ce dépassement budgétaire moyen que nous avons intégré pour objectiver l'écart de TCO sur 3 ans, à partir d'un projet de référence (budget de développement initial de 100 000 €), en y ajoutant une majoration de +30 % du poste maintenance pour refléter le poids de la dette technique généralement accumulée sur un développement propriétaire². Les autres postes (hébergement, évolutions, formations) restent basés sur des ordres de grandeur de marché standards.

¹ ² McKinsey Digital, "Losing from day one: Why even successful transformations fall short", 2020 (dépassement budgétaire moyen et valeur délivrée) ; "Technology's generational moment with generative AI", 2022 (dette technique estimée à 20-40 % de la valeur du parc applicatif).
Modèle indicatif construit à partir d'un projet de référence. Ne remplace pas un chiffrage projet réel.

Une série de postes de coûts à considérer

Un projet IA construit en interne doit absorber une série de postes parfois sous-estimés au départ :

• Cadrage fonctionnel et spécifications
• Développement initial
• Tests et corrections
• Mise en production
• Hébergement
• Infrastructure
• Connecteurs et calls API
• Sécurité et conformité RGPD
• Maintenance évolutive et monitoring
• Support
• Temps interne de pilotage

Ces coûts ne sont pas exceptionnels. Ils constituent le socle réel d’un logiciel qui doit durer. On voit bien que le coût de développement initial ne représente qu’une partie de l’équation.

Dans le cas d’un projet de satisfaction retail, il faut gérer les envois SMS et email, suivre la délivrabilité, éviter les filtres opérateurs et les spams, segmenter les audiences, connecter le projet au CRM, au POS et au reste du SI, puis garantir que les remontées terrain soient fiables et exploitables magasin par magasin.

Ce que l’on perd en construisant seul

Construire en interne, c’est aussi renoncer à plusieurs effets de levier qu’une plateforme SaaS déjà mature a progressivement accumulés : mutualisation, spécialisation, apprentissage sectoriel, vitesse d’exécution et résilience opérationnelle.

Les synergies d’une solution « clé en main »

Le premier renoncement, ce sont les synergies. Une plateforme SaaS concentre ses efforts sur un même produit, avec des améliorations continues, des retours clients croisés et une logique de standardisation qui profite à tous les utilisateurs. À l’inverse, un outil construit pour une seule enseigne reste isolé : il n’absorbe pas les apprentissages d’autres secteurs, d’autres réseaux, d’autres cas d’usage. Ce qui est appris d’un client ne profite à personne d’autre.

Les économies d’échelle

Dans le SaaS, plus la base clients est large, plus les coûts d’infrastructure, d’exploitation, de tests et de support se diluent. Dans un projet interne, tout repose sur un seul usage, un seul volume, un seul contexte technique, donc un coût unitaire plus élevé sur les canaux, l’infrastructure et les opérations. C’est particulièrement vrai dès qu’on parle de SMS, d’email, de connecteurs, de supervision ou de montée en charge

La spécialisation

Dans une solution dédiée au pilotage de la satisfaction, la vraie valeur ne tient pas uniquement à l’outil mais à l’expertise métier embarquée : bonnes pratiques CX, wording des sollicitations, stratégie de relance, délivrabilité, timing d’envoi, logique de questionnaire, lecture des benchmarks. Un projet interne peut reproduire une interface. En revanche, c’est beaucoup plus difficile de reproduire des années d’apprentissage sur ce qui fait vraiment remonter la qualité des réponses.

Le time-to-value

Un outil construit seul doit être cadré, développé, testé, intégré et stabilisé avant de produire de la valeur tangible. Une solution SaaS, elle, est déjà prête à l’emploi et capitalise sur des retours d’expérience multiples. La question, quand vous lancez un projet build, c’est “combien de temps faudra-t-il avant d’avoir une solution réellement utile, fiable et adoptée par les équipes ?”.

La résilience

Un build interne dépend fortement d’une petite équipe, parfois d’une seule personne clé et de sa disponibilité dans le temps. En cas d’absence, de turnover ou de réorganisation, le projet peut être déstabilisé. A l’inverse, une plateforme SaaS repose sur une équipe produit, technique et support qui assure la continuité, l’évolution et la maintenance du service.

Synthèse/conclusion

Chez WizVille, nous pensons que l'IA a le potentiel de réinventer la capacité à piloter la satisfaction client. Nous sommes convaincus que la prochaine décennie appartiendra aux enseignes qui feront de la satisfaction client un avantage concurrentiel quantifié et piloté par l'IA. Depuis 2022, nous intégrons l’IA dans notre produit pour mettre sa puissance aux services des équipes retail.

En revanche, l’intelligence artificielle n’a pas supprimé la complexité d’un logiciel métier. Elle permet de prototyper plus vite, mais pas de s’affranchir des fondamentaux : architecture, intégration, maintenance, conformité, qualité de la donnée, gouvernance.

L’IA ne code pas tout, et surtout, elle ne transforme pas à elle seule un POC en solution robuste et réellement exploitable à l’échelle. Aujourd’hui, une grande majorité de projets IA ne créent pas d’impact mesurable et ne passent pas la barre de l’industrialisation.

Avant de lancer un projet IA de pilotage de la satisfaction client en interne, demandez-vous surtout si vous avez la capacité de le faire vivre, le fiabiliser et d’en tirer une valeur durable dans le temps.

Dans un projet de satisfaction retail, le coût réel ne se limite pas au développement initial. Le TCO d’un build interne dépasse souvent le simple budget de départ, sans même compter le coût d’une reprise si le projet cale en route. Au-delà du coût, construire seul fait aussi perdre des leviers décisifs : synergies d’une plateforme déjà mature, économies d’échelle, spécialisation métier, time-to-value, …

Choisir une solution comme WizVille, c’est s’appuyer sur une expertise déjà industrialisée, des années d’apprentissage métier, une infrastructure éprouvée et une capacité à faire progresser la qualité du pilotage dans la durée. Au lieu de reconstruire une chaîne complète en interne, vous gagnez du temps, vous réduisez le risque projet et vous vous concentrez sur votre cœur de métier : piloter la satisfaction et l’expérience client.