IA dans votre logiciel : fonctionnalité ou architecture ?
La plupart des outils estampillés IA sont de vieux logiciels avec un chatbot collé dessus. La vraie question n'est pas le modèle utilisé, c'est comment l'IA est intégrée dans le produit.
Un chatbot greffé n'est pas un produit IA
Le marché des logiciels "IA" grossit vite. Le contenu, lui, ne suit pas toujours. Une grande partie de ce qui se vend comme "IA-native" est en réalité une application existante sur laquelle un chatbot a été vissé en surface. C'est la différence entre peindre une voiture en rouge et changer le moteur.
Pour une PME qui évalue un outil, la distinction est concrète : un chatbot greffé ne change pas votre workflow, il ajoute une interface de plus. Un produit conçu autour de l'IA restructure ce que vous faites et comment.
Ce que les éditeurs ne vous disent pas
La plupart des éditeurs ne distinguent pas les deux approches dans leur communication. Le mot "IA" apparaît dans la fiche produit, dans le tarif, dans la démo. Ce qui n'apparaît pas, c'est l'architecture sous-jacente.
Un exemple cité par Benjamin Derville dans sa chronique pour le Journal du Net : GitHub Copilot a ajouté de l'IA à un IDE existant. Claude Code a repensé le flux de travail autour de l'IA. Le premier est une aide. Le second est un changement de méthode.
Cette distinction concerne directement les PME en phase d'équipement. Payer un surcoût "IA" pour obtenir un chatbot qui répond à côté parce qu'il n'a pas accès au bon contexte, c'est le cas le plus fréquent et le plus silencieux. Personne ne se plaint ouvertement d'un outil qu'on a acheté cher.
Le mécanisme qui sépare l'utile de l'accessoire
Trois éléments permettent de distinguer un produit IA réel d'un habillage marketing.
Premier point : l'agent a-t-il accès aux mêmes données que l'utilisateur ? Un chatbot e-commerce incapable de voir la fiche produit consultée par le client ne peut pas aider le client. Un outil de support qui ne lit pas le contexte du ticket précédent ne gagne pas de temps. La parité d'accès est le test le plus simple.
Deuxième point : l'IA filtre-t-elle ou produit-elle ? Un outil bien conçu ne génère pas plus de volume, il réduit ce que vous devez traiter. Sur 50 notifications, il vous en signale 3. Sur un rapport de 30 pages, il extrait les 2 chiffres qui changent une décision. Si votre outil produit de la matière supplémentaire à relire, il vous coûte de l'attention au lieu de vous en faire gagner.
Troisième point : pouvez-vous contrôler ce que l'agent sait et décide ? Les erreurs des systèmes IA viennent rarement du modèle lui-même. Elles viennent du contexte fourni au modèle. Si vous ne pouvez pas voir ses sources, corriger sa mémoire, limiter ses actions sur certaines opérations critiques, vous avez un outil opaque. La confiance dans un outil IA se construit avec des garde-fous visibles, pas sans eux.
Ce que ça change dans l'évaluation d'un outil
Avant de signer un contrat SaaS avec un badge IA, trois questions concrètes à poser au commercial.
Un : à quelles données de votre environnement l'outil a-t-il accès en temps réel ? Pas en théorie, pas "via connecteur à configurer". En pratique, dans la version que vous achetez.
Deux : l'outil réduit-il votre charge de traitement ou augmente-t-il votre volume de matière à lire ? Demandez une démonstration sur vos propres données si possible.
Trois : pouvez-vous voir et modifier le contexte que l'IA utilise pour prendre ses décisions ? Si la réponse est "c'est géré en interne par notre modèle", c'est une boîte noire.
La question n'est pas de savoir si l'outil utilise GPT-4o ou Claude 3.5. Ces modèles sont devenus des commodités accessibles à tous les éditeurs. Ce qui reste rare, c'est l'architecture produit qui leur donne un rôle réel dans votre chaîne de travail.