Intégrer l’IA dans un SaaS B2B crée de la valeur quand elle allège une tâche précise, fréquente et mesurable, dans l’écran où l’utilisateur travaille déjà. Elle en détruit quand elle prend la forme d’un assistant générique que personne ne sait comment interroger. Le bon point de départ n’est donc pas le choix d’un modèle, mais celui d’une tâche, d’un niveau de contrôle humain et d’une mesure.
Depuis deux ans, beaucoup d’éditeurs ont ajouté une bulle de discussion à leur produit. Les utilisateurs l’essaient une fois, puis l’oublient. Cet article donne une méthode pour faire mieux : repérer les bons usages, décider qui tranche, prouver le gain et tenir compte du RGPD, de la nLPD suisse et de l’AI Act européen.
Où l’IA crée-t-elle de la valeur dans un SaaS B2B ?
Vos utilisateurs n’ouvrent pas votre logiciel pour découvrir de l’IA. Ils l’ouvrent pour traiter des dossiers, valider des commandes, suivre des échéances. L’IA utile raccourcit ce travail sans ajouter une étape à apprendre.
Le Nielsen Norman Group l’a observé en test utilisateur : les fonctions d’IA au périmètre étroit sont, en général, plus faciles à comprendre et à adopter pour les nouveaux utilisateurs que les outils ouverts. Une fonction qui fait une chose, bien, l’emporte sur un assistant qui promet de tout faire.
Les quatre familles d’usages qui reviennent
Dans les produits que nous concevons, les usages utiles se rangent presque toujours dans quatre familles :
- repérer : signaler ce qui demande de l’attention, comme une échéance proche, une anomalie, un dossier bloqué ;
- préparer : pré-remplir une commande, une réponse, un rapprochement, que l’utilisateur n’a plus qu’à vérifier ;
- synthétiser : résumer un historique client, une série de tickets, un dossier de cinquante pages ;
- classer et extraire : ranger des pièces jointes, lire des champs dans un document, rapprocher deux sources.
Aucune n’est spectaculaire. C’est ce qui les rend rentables : elles touchent des gestes répétés chaque semaine.
La conversation libre n’en fait pas partie par défaut. Elle a sa place quand la question de l’utilisateur est vraiment imprévisible, par exemple une recherche dans une documentation volumineuse. Ailleurs, elle déplace l’effort vers l’utilisateur, qui doit formuler sa demande au lieu de cliquer.
Le bon emplacement : dans l’écran, pas à côté
La même fonction peut réussir ou échouer selon l’endroit où elle apparaît. Une suggestion affichée dans la liste que l’utilisateur consulte déjà sera vue. La même suggestion rangée dans un menu « Assistant » sera ignorée.
Prenons un écran de gestion des équipements de protection, comme celui d’EPItrack Manager, dont le studio a conçu l’interface. Les situations non conformes y ressortent au premier coup d’œil. Une fonction IA bien placée irait un cran plus loin : à côté des collaborateurs en alerte, une commande groupée déjà préparée, avec un bouton pour la valider.
EPItrack Manager, interface conçue par Brutux Studio : l’endroit où une suggestion IA serait vue.
Un écran surchargé ne laisse aucune place lisible à une suggestion. Si vos utilisateurs se perdent déjà dans l’interface, lisez d’abord les signes qu’une refonte de SaaS B2B s’impose : l’IA amplifie la clarté d’un produit, elle ne corrige pas son désordre.
Comment choisir les premiers cas d’usage ?
La plupart des éditeurs ont trop d’idées, pas trop peu. Le travail consiste à en garder deux ou trois, sur des critères vérifiables. Nous en utilisons trois, puis une grille simple pour trancher.
Trois questions pour chaque idée
Quelle tâche vos utilisateurs répètent-ils le plus ? Cherchez dans les données d’usage, les tickets de support et les entretiens. Une tâche faite deux fois par mois ne justifie pas un projet, même si elle est pénible.
Combien de temps prend-elle aujourd’hui ? Chronométrez-la sur quelques utilisateurs réels, même grossièrement. Sans ce point de départ, personne ne pourra dire plus tard si l’IA a changé quelque chose.
Que coûte une erreur ? Un résumé imparfait se corrige en dix secondes. Une mauvaise ligne de facturation ou un statut de conformité erroné engage votre client. Ce coût décide du rôle que vous pourrez confier à l’IA.
Une matrice gain et risque pour trancher
Placez chaque idée sur deux axes : le temps gagné et le coût d’une erreur. La matrice ci-dessous résume la décision qui en découle.
Fort gain et erreur bénigne : commencez là. Fort gain et erreur coûteuse : l’IA prépare, l’humain valide.
Le quart en haut à gauche est votre premier chantier : beaucoup de temps gagné, des erreurs sans gravité. Le quart en haut à droite reste intéressant, mais il impose une validation humaine systématique. Le reste attend ou disparaît de la liste.
Deux critères éliminent une idée, quelle que soit sa place dans la matrice. Le premier : les données nécessaires n’existent pas, ou sont trop dispersées pour être exploitées. Le second : personne, chez vous, ne pourra juger si la réponse de l’IA est juste.
Le cadre de gestion des risques du NIST formalise ce tri. Sa fonction « Map » doit fournir assez de contexte pour une première décision d’y aller ou non, avant de concevoir ou de déployer un système d’IA. Autrement dit : on a le droit de conclure qu’une idée ne vaut pas le coup.
Qui décide : l’IA ou l’utilisateur ?
Dans un produit B2B, l’erreur d’une IA devient l’erreur de votre client, puis la vôtre. La question centrale n’est donc pas « que sait faire le modèle ? » mais « qui décide, à quel moment, avec quelle information sous les yeux ? ». C’est ce qu’on appelle l’humain dans la boucle.
Trois niveaux d’autonomie
Nous distinguons trois rôles possibles pour une fonction IA, à choisir selon le coût d’une erreur.
Plus une erreur coûte cher, plus l’utilisateur garde la main.
Suggérer. L’IA propose une option, l’utilisateur la prend ou l’ignore. C’est le niveau idéal pour démarrer : le risque est faible et les refus vous apprennent beaucoup.
Préparer. L’IA construit l’action complète, mais rien ne part sans un clic de validation. C’est le niveau qui convient à la plupart des tâches à fort gain dans un logiciel métier.
Agir seule. Réservez ce niveau aux actions réversibles, journalisées et contrôlées par échantillon. Un classement de pièces jointes peut s’y prêter. Un envoi au client final, rarement.
Concevoir la validation, pas seulement le modèle
Une validation n’a de sens que si l’utilisateur peut juger ce qu’il valide. Montrez les éléments sources d’une synthèse. Distinguez visuellement ce que l’IA a produit de ce que l’utilisateur a saisi. Rendez la correction aussi rapide que l’acceptation.
Le piège inverse existe aussi. Sur notre page méthode CRAFT, nous citons une étude du MIT : des radiologues assistés par un outil d’IA y faisaient moins bien que seuls, parce qu’ils s’en remettaient à la machine précisément dans les cas où elle hésitait. Valider sans regarder n’est pas un contrôle humain.
C’est pourquoi l’interface doit aussi signaler les cas incertains, au lieu de présenter chaque proposition avec la même assurance. Et vos utilisateurs doivent savoir, concrètement, dans quels cas se méfier de la suggestion.
Comment mesurer le gain d’une fonction IA ?
Une fonction IA peut briller en démonstration et décevoir en production. La seule protection consiste à définir la mesure avant de construire, puis à la suivre une fois la fonction en ligne.
Avant de développer : un jeu de cas et une référence
Rassemblez une cinquantaine de cas réels, y compris les cas difficiles. Pour chacun, notez la bonne réponse et le temps qu’il faut aujourd’hui pour la produire. Ce jeu de cas permet de comparer plusieurs modèles sur vos propres données.
Fixez aussi le seuil à partir duquel la fonction vaut la peine. Par exemple : une proposition jugée correcte sans retouche dans une large majorité des cas, et un temps de traitement nettement réduit. Ce seuil se décide avec les métiers, pas avec l’équipe technique seule.
Le NIST recommande de tester les systèmes d’IA avant leur déploiement, puis régulièrement en fonctionnement. Un modèle change, vos données aussi : un jeu de cas conservé permet de rejouer le test à chaque évolution.
Après la mise en production : trois indicateurs
Une fois la fonction livrée, suivez au minimum :
- le temps de traitement de la tâche, comparé à la mesure de départ ;
- le taux d’acceptation des suggestions, sans retouche, avec retouche ou refusées ;
- les corrections a posteriori : les erreurs repérées après validation, par l’utilisateur ou par son client.
Un taux d’acceptation très bas signale une fonction inutile ou mal placée. Un taux proche de 100 % avec des corrections a posteriori signale un autre problème : vos utilisateurs valident sans lire. Les deux chiffres se lisent ensemble.
Déployez d’abord sur quelques comptes volontaires. Leurs retours valent plus qu’un mois de tests internes.
Comment intégrer l’IA dans un SaaS en limitant le risque juridique ?
Pour un éditeur qui vend en France, en Suisse et dans l’Union européenne, trois textes entrent en jeu. Ce qui suit n’est pas un avis juridique, mais les points à poser dès la conception.
RGPD : analyse d’impact et minimisation
La CNIL rappelle qu’une analyse d’impact (AIPD) est exigée lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Un traitement qui remplit au moins deux des neuf critères du Comité européen de la protection des données est présumé concerné.
La même page précise un point utile aux éditeurs : quand le fournisseur ne couvre que la phase de développement, l’utilisateur responsable du traitement doit réaliser sa propre AIPD pour le déploiement. Clarifiez donc avec vos clients qui documente quoi.
La CNIL recommande aussi de privilégier la technique qui utilise le moins de données personnelles possible. Concrètement : n’envoyez au modèle que les champs nécessaires à la tâche, et pseudonymisez ce qui peut l’être.
nLPD : la loi suisse s’applique déjà à l’IA
En Suisse, le Préposé fédéral à la protection des données et à la transparence (PFPDT) indique que la loi en vigueur depuis le 1er septembre 2023 est directement applicable aux traitements de données fondés sur l’IA, sans attendre une loi dédiée.
Le PFPDT attend des fabricants, fournisseurs et exploitants qu’ils rendent transparents la finalité, le fonctionnement et les sources de données de leurs systèmes d’IA. Il rattache à cette transparence le droit de s’opposer à un traitement automatisé ou d’exiger qu’une personne réexamine une décision individuelle automatisée. Le niveau « préparer » de la section précédente répond naturellement à cette exigence.
Pour un éditeur qui vend à des clients genevois ou vaudois, ces questions arrivent tôt dans le cycle de vente. Nous les traitons dès le début avec les équipes de conseil IA à Genève et de Lausanne.
AI Act : ce qui s’applique déjà, et ce qui arrive
L’AI Act s’applique par étapes. Selon la page de la Commission européenne consacrée au règlement, les interdictions et l’obligation de maîtrise de l’IA s’appliquent depuis le 2 février 2025, et les obligations des fournisseurs de modèles d’IA à usage général depuis le 2 août 2025.
Le calendrier de l’AI Act après l’omnibus IA de 2026, d’après la Commission européenne.
| Échéance | Ce qui s’applique | Ce que cela change pour un SaaS B2B |
|---|---|---|
| 2 février 2025 | Pratiques interdites, maîtrise de l’IA | Former les personnes qui utilisent ou opèrent vos fonctions IA |
| 2 août 2026 | Transparence de l’article 50 | Signaler clairement une interaction avec une IA |
| 2 décembre 2027 | Haut risque, annexe III | Seulement si votre usage relève des domaines sensibles listés |
Sur la maîtrise de l’IA, la Commission précise que l’article 4 vise aussi les personnes qui opèrent ou utilisent un système d’IA pour le compte d’un fournisseur ou d’un déployeur, y compris des prestataires ou des clients. Depuis l’omnibus IA, aucun niveau « suffisant » précis n’est imposé, mais l’obligation demeure.
Depuis le 2 août 2026, l’article 50 impose d’informer les personnes qu’elles interagissent avec un système d’IA, de façon claire et dès la première interaction, sauf si c’est évident. Un assistant conversationnel est directement concerné. Pour une suggestion intégrée à l’écran, signaler sa nature reste une bonne pratique de conception, et un gage de confiance.
Pour les systèmes à haut risque, l’omnibus IA adopté en 2026 (règlement (UE) 2026/1744) a décalé l’échéance : la Commission indique le 2 décembre 2027 pour les usages sensibles de l’annexe III, et le 2 août 2028 pour l’IA intégrée à des produits réglementés. La plupart des fonctions d’un SaaS de gestion n’entrent pas dans ces catégories, mais vérifiez-le au cas par cas avec un juriste : ces dates sont celles connues en octobre 2026.
Quelles erreurs éviter, et par où commencer ?
Les projets qui échouent se ressemblent. Ils butent rarement sur la technologie, plutôt sur le choix de la tâche, la mesure ou la confiance des utilisateurs.
Les erreurs les plus fréquentes
- Annoncer l’IA avant de l’avoir rendue utile : un badge « propulsé par l’IA » ne remplace pas un gain visible.
- Choisir le modèle avant la tâche : la comparaison se fait sur vos cas, pas sur un classement public.
- Lancer sans mesure de départ : impossible ensuite de prouver le gain à vos clients ou à votre direction.
- Donner trop d’autonomie trop tôt : commencez par suggérer, montez d’un niveau quand les chiffres le justifient.
- Envoyer des données clients à un service tiers sans analyse : contrat, hébergement et minimisation se décident avant, pas après.
- Oublier les coûts à l’usage : un appel au modèle par écran affiché peut coûter plus cher que la valeur créée.
Une erreur plus discrète : confier l’IA à la seule équipe de développement. Les gains se jouent dans le métier de vos clients, donc le produit, le support et les commerciaux participent au choix des usages.
Un premier chantier en quatre temps
Pour un premier pas, gardez un périmètre étroit : une tâche, un écran, une mesure avant et après. Nous structurons ce travail avec les phases de la méthode CRAFT : Cartograph pour comprendre le contexte, Review pour diagnostiquer les processus et les données, Architect pour concevoir le système humain-IA, Frame pour prioriser et planifier, puis Transform pour déployer et suivre dans la durée.
Chaque phase produit un livrable écrit : rapport stratégique, matrice de maturité data et processus, spécification fonctionnelle, feuille de route à douze mois, plan de déploiement piloté. Ces documents restent la propriété de l’éditeur, qu’il réalise ensuite l’intégration en interne ou avec nous.
Le premier chantier tient en quatre temps : observer la tâche, arrêter le jeu de cas, prototyper l’écran, livrer à quelques comptes puis élargir.
Une fonction bien choisie, bien placée et mesurée vaut mieux qu’un assistant généraliste que personne n’ouvre. Si vous voulez savoir où l’IA ferait gagner du temps à vos utilisateurs, notre équipe d’intégration de l’IA dans votre logiciel peut regarder votre produit avec vous.
Sources
- Nielsen Norman Group, Scope in Generative AI Features : adoption des fonctions au périmètre étroit.
- NIST, AI RMF Core : décision d’y aller ou non, tests avant et après déploiement.
- CNIL, IA : réaliser une analyse d’impact si nécessaire : quand l’AIPD est exigée.
- CNIL, Recommandations sur le développement des systèmes d’IA : minimisation des données.
- PFPDT, La loi actuelle est directement applicable à l’IA : LPD, transparence, réexamen humain.
- Commission européenne, AI Act : calendrier d’application.
- Commission européenne, AI Literacy, Questions & Answers : article 4.
- Commission européenne, Transparency obligations under Article 50 : article 50.