SaaS et intelligence artificielle : le guide pour équiper un produit qui existe déjà

La première erreur : partir de la technologie plutôt que du moment où votre client perd du temps

La plupart des chantiers ratés commencent par la même phrase, prononcée en réunion de direction : « on va mettre de l'intelligence artificielle dans le produit ». C'est une décision sans destination. Elle ressemble à une stratégie, elle n'en est pas une : elle ne dit ni où dans le produit, ni pour quel type de client, ni pour remplacer quel geste aujourd'hui pénible et répété des dizaines de fois par jour.

La bonne question se pose dans l'autre sens, en partant de l'écran plutôt que de la technologie. Ouvrez votre produit et cherchez l'endroit précis où un utilisateur passe le plus de temps à faire quelque chose de répétitif : trier, résumer, classer, rédiger un texte proche d'un texte déjà écrit cent fois avant lui. C'est cet écran précis qui doit recevoir la fonction en premier, pas le produit entier revu d'un seul coup.

Cette discipline vaut pour tout logiciel construit sur mesure : on ne développe jamais « en général », on développe pour un geste identifié, mesuré, et répété assez souvent pour que le résoudre change réellement quelque chose au quotidien de la personne qui l'utilise chaque jour dans votre produit. Le même réflexe vaut avant de parler de modèle ou de fournisseur : on nomme d'abord le geste, on choisit la technologie après, jamais l'inverse, sous peine de construire quelque chose que personne ne demandait vraiment.

Un signe qui doit alerter tôt : si personne chez vous ne sait répondre à « qui va cliquer sur ce bouton, et combien de fois par semaine », le projet part de la technologie et pas de l'usage réel d'un client. Reprenez la question avant d'écrire la moindre ligne de code, le chantier sera plus court, moins cher, et plus juste une fois reposé sur un geste identifié plutôt que sur une intuition de départ.

Les trois chemins pour mettre de l'intelligence artificielle dans un SaaS existant

Trois façons de faire s'offrent à un éditeur de logiciel qui veut équiper son produit d'une fonction intelligente, et elles n'engagent pas votre entreprise de la même manière, ni sur le même horizon de temps. Comprendre ce qui les sépare évite de choisir un chemin lourd pour une question qui aurait pu se tester en quelques jours avec le plus simple des trois. Les trois se distinguent sur trois points précis : la rapidité de mise en route, le degré de dépendance à un fournisseur extérieur, et la part du budget qui va au développement plutôt qu'à l'usage mensuel.

La première consiste à appeler un modèle du marché par son interface de programmation : votre produit envoie une requête à un fournisseur (OpenAI, Anthropic, Mistral, selon le cas) et reçoit une réponse en retour. C'est le chemin le plus rapide à mettre en route, parfois en quelques jours. Il vous rend aussi dépendant d'un prix, d'une disponibilité et d'une politique de traitement des données que vous ne contrôlez pas, et que le fournisseur peut changer sans vous prévenir à l'avance.

La deuxième consiste à faire tourner un modèle chez vous ou chez un hébergeur que vous choisissez vous-même, sans que vos données sortent jamais vers un tiers extérieur. C'est le chemin qui pèse le plus lourd à mettre en route, en machines et en compétence à maintenir dans la durée, et c'est souvent celui qui rassure le plus les clients d'un éditeur qui vend lui-même à des entreprises sensibles à la confidentialité de leurs données.

La troisième consiste à construire une fonction dédiée à un usage précis de votre produit, comme une recherche qui retrouve une information dans des milliers de documents sans jamais l'inventer (c'est le principe expliqué dans le chapitre recherche documentaire augmentée). C'est le chemin le plus long à écrire, et celui qui rend le mieux compte de ce qui fait la valeur de votre produit, parce qu'il connaît vos données et vos règles métier au lieu de deviner à partir de ce qu'un modèle a appris ailleurs.

Rien n'empêche de commencer par le premier chemin pour tester une hypothèse sur un petit périmètre de clients, puis de basculer vers le troisième une fois l'usage prouvé et régulier. Ce qui coûte réellement cher, c'est de choisir d'emblée le troisième chemin avant d'avoir prouvé quoi que ce soit avec le premier, sur un vrai besoin client. Le troisième chemin se décline lui-même en deux versions : un développement entièrement propre à votre produit, ou un composant déjà prêt que vous branchez à votre produit et revendez sous votre propre marque, sans repartir d'une page blanche.

Ce que chaque chemin vous coûte, et ce qu'il vous engage

Appeler un modèle du marché se facture à l'usage : chaque requête a un prix, ce prix baisse ou monte selon le fournisseur et le mois, et il change parfois sans préavis long, sur simple décision commerciale du fournisseur concerné. Nous ne donnons pas de tarif précis ici, parce qu'il aurait de fortes chances d'être déjà faux au moment où vous lisez cette page. Ce qui compte, c'est de savoir que ce coût vit hors de votre contrôle et qu'il varie directement avec le succès de votre fonction : plus elle est utilisée par vos clients, plus elle vous coûte chaque mois.

Héberger un modèle chez vous inverse la logique : le coût devient fixe, une machine ou un serveur loué, indépendant du nombre de requêtes envoyées. C'est rassurant sur le papier et dangereux dans les faits pour un éditeur qui débute, parce que ce coût fixe tombe même les mois où la fonction est presque inutilisée. Il ne convient vraiment qu'à un usage déjà prouvé, régulier, et suffisamment large pour amortir la dépense engagée chaque mois.

Construire une fonction dédiée déplace le coût vers le développement plutôt que vers l'usage : vous payez le chantier une fois, puis vous en êtes propriétaire pour la suite. C'est le chemin qui protège le mieux votre marge sur le long terme quand vous vendez un abonnement à prix fixe, parce que l'utilisation croissante de la fonction par vos clients n'augmente pas mécaniquement votre facture d'exploitation, contrairement aux deux autres chemins.

L'engagement n'est pas seulement financier. Appeler un modèle du marché vous lie à un fournisseur : votre produit dépend de sa disponibilité, de ses conditions d'usage, et parfois de sa décision de retirer un modèle du catalogue du jour au lendemain. Avant de choisir, demandez-vous ce qui se passe pour vos clients le jour où ce fournisseur change ses règles, et surtout si vous pouvez basculer vers un autre sans devoir tout réécrire dans l'urgence.

Ce que ça change dans l'architecture d'un produit vendu à plusieurs clients

Un SaaS, c'est un seul produit qui sert plusieurs entreprises en même temps, et non un logiciel installé une fois chez un client unique, avec une promesse que chacune d'elles vous a faite en signant : ses données restent les siennes, et personne d'autre ne les voit, jamais, même par accident technique. Ajouter de l'intelligence artificielle ne dispense pas de cette promesse, elle l'expose davantage, parce qu'un modèle traite les données qu'on lui donne à lire au moment de la requête.

Le point à vérifier avant tout le reste : quand votre produit interroge un modèle pour le compte du client A, est-ce que le modèle voit uniquement les données du client A, ou est-ce qu'il a accès, même indirectement, à des données d'autres clients à travers un contexte partagé, un cache commun ou un index mal cloisonné entre les comptes ? Cette question se pose une fois, par écrit, avant l'écriture du code, jamais après coup.

L'erreur la plus fréquente chez un éditeur qui ajoute vite une fonction intelligente : réutiliser un même espace de travail pour entraîner ou affiner un modèle sur les données de plusieurs clients à la fois, pour gagner du temps de développement au départ. Ce raccourci fonctionne très bien en démonstration interne et devient un problème contractuel sérieux dès le premier client qui demande, noir sur blanc, comment ses données sont traitées et isolées.

Concrètement, cela veut dire concevoir la fonction avec les mêmes réflexes que le reste de votre produit multi-clients : un identifiant de client qui accompagne chaque requête sans exception, une vérification à chaque étape que la réponse ne mélange rien entre deux comptes, et une trace de ce qui a été envoyé au modèle, pour pouvoir répondre précisément le jour où un client pose la question par écrit à votre équipe.

L'isolation des données entre vos clients : ce qui devient dangereux

L'isolation des données existe déjà dans votre produit, probablement depuis le premier jour de son existence : une base par client, ou des colonnes qui séparent chaque compte à l'intérieur d'une même base. Ce cloisonnement, qui fonctionne bien pour des lignes rangées dans une base de données, ne se transporte pas automatiquement dans un modèle d'intelligence artificielle, parce qu'un modèle ne raisonne pas en lignes séparées, il raisonne sur tout ce qu'on lui a donné à lire dans une même requête envoyée.

Le danger le plus concret apparaît quand une fonction intelligente s'appuie sur un contexte enrichi automatiquement pour mieux répondre, par exemple en allant chercher des exemples similaires ailleurs dans votre base pour améliorer une suggestion faite à l'utilisateur. Si ce mécanisme n'est pas strictement filtré par client, un exemple appartenant au client B peut apparaître dans une réponse donnée au client A, sans que personne chez vous ne l'ait programmé exprès ni même remarqué.

Un deuxième point mérite d'être vérifié tôt dans le chantier : ce que devient une donnée une fois envoyée à un fournisseur externe de modèle. Certains contrats de fournisseurs autorisent, sauf option contraire cochée explicitement, la réutilisation des requêtes pour améliorer leurs propres modèles avec le temps. Pour un éditeur qui promet la confidentialité à ses clients, cette option doit être désactivée et vérifiée par contrat, jamais simplement supposée ou laissée par défaut.

Ce chantier de cloisonnement se prépare avant d'écrire la fonction elle-même, pas après coup une fois qu'un incident a été signalé. Il coûte peu à concevoir dès le départ, avec les bonnes questions posées à votre développeur ou à votre prestataire, et beaucoup à corriger une fois la fonction livrée à cent clients qui l'utilisent déjà au quotidien. Une simple liste de vérification, relue avant chaque nouvelle fonction touchant à plusieurs clients à la fois, suffit la plupart du temps à éviter l'oubli qui coûte le plus cher à corriger après coup.

Le coût réel d'une fonction d'intelligence artificielle dans votre produit

Le développement d'une fonction dans le produit d'un éditeur se chiffre chez nous en plusieurs dizaines de milliers d'euros, et non en quelques milliers : le travail porte sur votre code existant, avec vos propres développeurs associés à chaque étape, ce qui prend plus de temps qu'un développement isolé, posé à côté du reste sans rien connecter. Les fourchettes chiffrées sont dans la foire aux questions, en bas de page.

Ce qui reste prévisible dans ce coût : le temps de développement, le temps de test avant mise en production, l'intégration à votre produit existant et à ses règles métier. Ce qui l'est beaucoup moins : le coût d'usage d'un modèle appelé par API, qui dépend directement du nombre de vos clients qui adoptent la fonction et de la fréquence à laquelle ils s'en servent au fil des semaines. Une fonction qui séduit plus vite que prévu peut faire grimper une facture mensuelle sans que personne ne l'ait anticipé au moment du cadrage.

L'effet sur votre marge se joue précisément là. Si vous vendez votre SaaS à prix fixe par abonnement et que le coût d'une fonction augmente avec l'usage, chaque client qui utilise beaucoup la fonction rogne un peu plus votre marge sur cet abonnement, mois après mois. Certains éditeurs répondent par un quota inclus et un dépassement facturé à part, d'autres réservent la fonction à un plan tarifaire supérieur. Décidez du modèle avant de lancer la fonction, pas six mois après avoir découvert le problème sur une facture de fournisseur.

Un dernier point, souvent oublié dans le calcul initial : le coût de maintenance dans la durée. Un modèle du marché évolue régulièrement, une nouvelle version remplace l'ancienne, parfois avec un comportement légèrement différent d'une réponse à l'autre. Quelqu'un chez vous doit surveiller ce changement et vérifier que la fonction répond toujours correctement, exactement comme on surveille une dépendance logicielle ordinaire dans votre produit. Ce temps de surveillance se planifie dès le départ, avec un nom de responsable et une fréquence de vérification, plutôt que d'être découvert le jour où un client signale qu'une réponse ne ressemble plus à ce qu'elle était la semaine d'avant.

La confidentialité : ce que vos clients vont vous demander de garantir

Un client d'un SaaS professionnel a déjà, la plupart du temps, une politique interne sur ce qu'il accepte d'envoyer à un fournisseur externe de service. Le jour où vous annoncez une fonction d'intelligence artificielle, son équipe juridique ou sa direction des systèmes d'information va poser des questions précises, et attendre des réponses écrites, documentées, pas des réponses orales données rapidement en rendez-vous commercial.

Les questions reviennent presque toujours dans le même ordre : quel fournisseur de modèle vous utilisez exactement, où sont hébergées les données pendant le traitement de la requête, combien de temps sont-elles conservées ensuite, sont-elles réutilisées pour entraîner un modèle, et pouvez-vous désactiver la fonction pour un client précis qui refuse d'y être exposé. Préparer ces réponses avant qu'on vous les demande évite de les improviser sous pression, en pleine négociation de renouvellement de contrat.

Un deuxième sujet de confiance se glisse souvent derrière la confidentialité, sans porter tout à fait le même nom : la fiabilité de ce que répond la fonction elle-même. Un client qui découvre qu'une réponse générée contenait une information fausse pose une question de confiance dans votre produit, pas seulement de bug technique isolé. Le chapitre ce qu'un modèle invente explique pourquoi ce risque existe structurellement et comment le réduire dès la conception de la fonction, avant qu'un client ne le découvre seul.

La bonne pratique consiste à écrire, avant le lancement, une page ou un document court qui répond aux questions attendues : fournisseur utilisé, localisation du traitement, durée de conservation, réutilisation ou non des données, moyen de désactivation pour un client réticent. Vos commerciaux gagnent un temps précieux le jour où ils peuvent transmettre ce document tout de suite, plutôt que de promettre une réponse dans les prochains jours à un client qui attend déjà.

Comment mesurer si la fonction sert vraiment

Une démonstration réussie ne prouve rien de durable. Un développeur qui teste sa propre fonction avec des données qu'il connaît par cœur, un jeudi après-midi concentré, obtient presque toujours un bon résultat devant ses collègues. La vraie question arrive après le lancement : un client ouvre-t-il la fonction une deuxième fois, une semaine plus tard, sans qu'on le lui rappelle par un email ou une notification.

Le piège le plus fréquent chez un éditeur de logiciel : confondre l'enthousiasme du lancement avec un usage durable installé dans les habitudes. La fonction reçoit des clics la première semaine parce qu'elle est nouvelle et mise en avant partout dans le produit, puis retombe à presque rien une fois la nouveauté passée et l'attention détournée ailleurs. Sans mesure suivie, cette chute passe totalement inaperçue, et la fonction continue de coûter en maintenance et en appels au modèle pour un usage presque nul chez la majorité des clients.

Trois chiffres suffisent à suivre honnêtement une fonction dans la durée : combien de comptes clients l'ont ouverte au moins une fois, combien l'ont rouverte après la première semaine sans relance de votre part, et combien de fois en moyenne par mois pour un utilisateur régulier. Le deuxième chiffre est le plus révélateur des trois : une fonction ouverte une fois et jamais revue n'a résolu aucun geste répétitif, elle a seulement satisfait une curiosité passagère.

Si ces chiffres restent bas trois mois après le lancement, la bonne réaction n'est pas d'ajouter une fonctionnalité supplémentaire pour relancer artificiellement l'intérêt, c'est de retourner voir les clients qui ne l'utilisent pas et de leur demander pourquoi, directement, en quelques minutes d'échange. La réponse obtenue en entretien est souvent plus utile que n'importe quelle donnée d'usage affichée dans un tableau de bord interne.

Ce qu'il faut avoir décidé avant d'écrire la première ligne

Cinq décisions méritent une réponse écrite avant le début du développement, pas pendant que le code avance déjà. Les prendre à froid, en une réunion préparée, coûte une réunion. Les découvrir en cours de chantier, sous la pression d'une échéance, coûte souvent des semaines de retour en arrière sur du code déjà écrit. Ces cinq décisions ne demandent pas d'expertise technique particulière, seulement de la clarté et un peu de temps posé au calme, avant que le développement n'avance et ne rende chaque changement plus coûteux qu'au premier jour.

La tâche précise que la fonction résout, avec la fréquence à laquelle un utilisateur la rencontre aujourd'hui dans son travail quotidien. Le chemin technique choisi parmi les trois possibles décrits plus haut, et la raison de ce choix plutôt que les deux autres écartés. La manière dont les données de chaque client resteront isolées des autres, écrite noir sur blanc dans un document, pas laissée à l'intuition de la personne qui écrit le code au fil de l'eau.

Le modèle de facturation proposé à vos clients : la fonction est-elle incluse dans l'abonnement existant sans surcoût, réservée à un plan tarifaire supérieur, ou vendue en option payante séparée. Et enfin, les chiffres précis qui diront dans trois mois si la fonction a réussi ou non, décidés avant le lancement du premier groupe de clients, pas inventés après coup pour justifier un résultat déjà connu et parfois décevant.

Un éditeur qui arrive avec ces cinq réponses écrites, posées à froid, gagne un temps considérable sur le chantier lui-même, parce que les décisions les plus coûteuses à changer en cours de route sont déjà prises avant que le développeur ouvre son éditeur de code. Un éditeur qui arrive sans elles finit souvent par les prendre en urgence, au pire moment possible, sous la pression d'un client qui attend une réponse depuis trop longtemps.

Construire en interne ou faire construire : comment trancher pour un éditeur de logiciel

La question n'est pas une question de compétence générale, elle est une question de disponibilité et de risque sur votre feuille de route produit. Vos développeurs connaissent votre produit mieux que quiconque au monde, mais ils connaissent rarement les pièges spécifiques d'une fonction d'intelligence artificielle : isolation des données entre clients, coût qui varie avec l'usage réel, comportement d'un modèle qui change d'une version à l'autre sans prévenir. Apprendre ces pièges sur votre tout premier chantier coûte du temps que vous n'aviez pas prévu de perdre en cours de route.

Construire en interne a du sens quand la fonction touche au cœur de votre produit et que vous voulez que vos développeurs en gardent la maîtrise complète sur le long terme, quitte à avancer plus lentement le temps qu'ils montent en compétence sur un sujet qu'ils découvrent au fil du chantier lui-même. C'est le bon choix quand vous avez déjà un peu de marge dans votre feuille de route et que personne chez vos concurrents n'a encore résolu ce même geste mieux que vous ne pourriez le faire vous-même, avec le temps qu'il faut.

Faire construire a du sens pour un premier chantier, quand vous voulez valider une hypothèse rapidement sans immobiliser toute votre équipe sur un sujet qu'elle ne maîtrise pas encore, et sans recruter une personne dédiée pour une fonction dont vous ne savez même pas encore si elle va durer dans le temps. C'est le principe derrière un développement mené dans le dépôt de votre produit, avec vos propres développeurs associés au travail : vous gardez la main, vous montez en compétence en même temps que le chantier avance, et vous n'avez rien à réapprendre seul le jour où il faut faire évoluer la fonction plus tard.

Ces deux options ne s'excluent pas dans le temps, elles se succèdent souvent : beaucoup d'éditeurs font construire le premier chantier avec un accompagnement extérieur, pour aller vite et éviter les erreurs qui coûtent le plus cher à corriger après coup, puis reprennent la main en interne une fois la fonction stabilisée et l'usage prouvé sur plusieurs mois consécutifs. Ce passage de relai se prépare aussi par contrat, avec un code documenté et lisible dès le premier jour, pour que vos développeurs puissent reprendre la fonction sans devoir la redécouvrir entièrement depuis zéro.

La propriété du code et la réversibilité : ce qu'un éditeur ne doit jamais perdre

Un éditeur de logiciel vend une chose avant toute autre : la confiance que son produit lui appartient et qu'il peut le faire évoluer sans dépendre de personne d'autre pour toujours. Ajouter une fonction d'intelligence artificielle ne doit jamais abîmer cette confiance, même pour un premier chantier modeste. Avant de signer avec qui que ce soit, une question simple règle presque tout : à qui appartiendra le code une fois le projet terminé et livré ?

La réponse doit être écrite noir sur blanc dans le contrat, jamais simplement supposée entre deux échanges d'emails. Un code livré dans votre propre dépôt, documenté, que vos développeurs peuvent lire et modifier sans l'auteur d'origine, vous rend réversible : vous pouvez changer de prestataire, embaucher quelqu'un en interne, ou arrêter la collaboration sans perdre la fonction construite. Un code qui reste hébergé chez un prestataire, accessible seulement par son interface à lui, vous rend dépendant de sa survie et de sa bonne volonté future.

Nous avons construit ce genre de fonction pour un éditeur de logiciel avec exactement ce principe en tête : le cas Cortex OS montre un moteur d'intelligence artificielle générative intégré directement dans le produit de l'éditeur, sans qu'il perde la main sur son propre code une fois le chantier terminé et les équipes reparties. Ce principe guide chacun de nos chantiers avec un éditeur de logiciel : le code livré doit pouvoir vivre et évoluer sans nous, ce qui change la façon dont on l'écrit dès la première ligne, pas seulement au moment de la remise finale.

La réversibilité se vérifie aussi dans le détail technique du contrat : si le chantier repose sur un modèle du marché appelé par une interface de programmation, pouvez-vous en changer sans réécrire toute la fonction concernée ? Si la réponse est non, parce que le code est écrit pour un seul fournisseur sans aucune séparation entre les deux couches, vous avez gagné une fonction et perdu une liberté, ce qui finit toujours par se payer plus cher que prévu à l'usage.

Le rythme d'un premier chantier, et les signes qu'il part mal

Un premier chantier raisonnable, sur une fonction bien délimitée dans un produit existant, se déroule en général sur quelques semaines à deux ou trois mois, du cadrage initial à la mise à disposition d'un premier groupe de clients volontaires. Un chantier qui s'annonce sur une année entière dès le départ mérite d'être découpé en morceaux plus petits : personne ne devrait attendre douze mois pour savoir si une fonction sert réellement à ses clients.

Le bon rythme commence petit : une version limitée à un groupe restreint de clients volontaires, avant l'ouverture à tous les autres. Ce groupe restreint sert à vérifier trois choses en conditions réelles avant d'engager le reste du budget : la fonction répond-elle correctement aux vraies questions posées, le coût d'usage reste-t-il dans l'ordre de grandeur prévu au départ, et les clients reviennent-ils l'utiliser une deuxième fois de leur propre initiative.

Un premier signe qui doit alerter tôt : le périmètre s'élargit en cours de route sans qu'aucune version n'ait encore été livrée à un client réel. « Pendant qu'on y est, on pourrait aussi faire... » est la phrase qui transforme un chantier de six semaines en chantier de six mois, et qui repousse indéfiniment le moment où un vrai client touche enfin la fonction promise. La parade est simple à énoncer, plus difficile à tenir : figer le périmètre par écrit avant le début du chantier, et ranger toute idée nouvelle dans une liste pour une prochaine version, plutôt que de la glisser dans celle en cours.

Un deuxième signe à surveiller : personne ne peut dire, à mi-chemin du chantier, ce que fera concrètement la fonction pour l'utilisateur final, en une phrase simple et compréhensible. Si la réponse ressemble à une liste de technologies employées plutôt qu'à un geste résolu pour un client, le projet a dérivé loin de son point de départ et mérite d'être recadré avant d'aller plus loin dans le développement.

Un troisième signe, le plus coûteux à ignorer sur la durée : le premier groupe de clients testeurs ne revient pas de lui-même vers la fonction, et il faut le relancer à chaque fois par email pour obtenir un simple retour d'usage. Un produit qui marche vraiment se réutilise sans qu'on ait à le rappeler sans cesse. C'est le signal le plus fiable de tous, bien avant n'importe quel chiffre de satisfaction déclarée en entretien téléphonique.