Outil IA déjà prêt ou assistant intégré : quand faut-il personnaliser

La question qui mène hors piste est « quelle intelligence artificielle est la meilleure ». Celle qui mène à une décision est plus ennuyeuse : cette tâche, réalisée avec l'outil que l'entreprise paie déjà, produit-elle un résultat utilisable ? Si la réponse est oui, il n'y a rien à développer. Si c'est non, la raison du non dit avec précision ce qu'il faut construire.

Presque toutes les évaluations s'enlisent parce qu'on compare des produits au lieu de comparer des tâches. Un produit se juge dans l'abstrait et c'est toujours celui qui a la meilleure démonstration qui gagne ; une tâche se juge sur le résultat, et le résultat, c'est vous qui savez le reconnaître.

On définit d'abord la tâche, ensuite on regarde les outils

Une tâche évaluable est spécifique, récurrente et a une issue reconnaissable. Il faut l'écrire, en quatre lignes.

• Ce qui entre : un message, un document, un enregistrement, une question.
• Ce qui doit sortir et sous quelle forme : un texte, une ligne dans un système, une classification, une réponse à un client.
• Qui le fait aujourd'hui, combien de fois par semaine, et combien de temps cela prend.
• Ce qui rend un résultat acceptable et ce qui le rend inacceptable. C'est la partie que presque personne n'écrit, et c'est la seule qui rend une comparaison possible.

« Utiliser l'intelligence artificielle pour le service client » n'est pas une tâche, c'est une catégorie. « Classer les demandes entrantes et proposer la réponse pour les trois catégories les plus fréquentes » en est une, et cela peut se tester en une semaine.

Le test : même cas, mêmes critères, mêmes personnes

La comparaison n'a de sens que si elle est comparable. Un protocole minimal, qui ne nécessite pas de compétences techniques.

1. On rassemble vingt ou trente cas réels déjà traités, y compris les cas difficiles et ceux où la personne s'est trompée. Ne prendre que des cas faciles produit une conclusion fausse.
2. On établit d'abord comment on juge : quelles erreurs sont acceptables et lesquelles ne le sont pas. Une erreur que le destinataire ne remarquerait pas et une erreur qui envoie une donnée fausse à un client ne pèsent pas pareil.
3. On donne le même matériau à chaque solution testée, instructions comprises. Si l'une reçoit des indications meilleures que les autres, vous mesurez qui a écrit les instructions.
4. Juge celui qui fait ce travail aujourd'hui, pas celui qui a proposé l'outil.
5. On note aussi le temps de révision. Une solution qui produit des résultats légèrement meilleurs mais doit être contrôlée ligne par ligne peut coûter plus cher que le travail qu'elle remplace.

Les quatre vérifications qui séparent un produit prêt à l'emploi d'un système intégré

Quand le test avec l'outil générique ne suffit pas, la raison relève presque toujours de l'un de ces quatre points. Savoir lequel évite de développer plus que nécessaire.

De nombreuses situations se résolvent avec un produit standard plus une connexion aux bonnes sources, sans construire de système. C'est la solution que personne ne propose, car elle est la moins vendable, et c'est souvent la plus sensée.

Ce qu'un produit prêt à l'emploi fait mieux qu'un développement

Cela vaut la peine de les énumérer, car dans l'empressement à personnaliser on jette de vrais avantages.

• Il s'améliore sans que vous ayez rien à faire, et ne dépend pas d'une seule personne qui sait comment il est fait.
• Il coûte moins cher à démarrer et permet de changer d'avis. Un test qui a duré trois semaines puis a été abandonné est un bon résultat, pas un gaspillage.
• Il a déjà été utilisé par beaucoup : les problèmes évidents sont apparus ailleurs, pas chez vous.
• Il ne génère pas de maintenance de votre côté. Tout ce qui est construit sur mesure doit être entretenu, et la maintenance ne finit jamais.

Le développement sur mesure se justifie quand la tâche dépend de données, de règles ou de systèmes qui n'appartiennent qu'à vous, quand les données ne peuvent pas sortir, ou quand la même opération se répète assez souvent pour rendre le travail manuel intenable.

Le coût invisible : supervision et maintenance

La comparaison honnête ne se fait pas entre l'abonnement d'un produit et le devis d'un développement. Ce sont les postes récurrents qui décident, et ils valent pour les deux voies.

• Qui contrôle les résultats, à quelle fréquence, et pendant combien de temps avant de relâcher le contrôle.
• Qui met à jour les sources quand changent les tarifs, les procédures ou les documents. Un système qui répond sur des documents obsolètes est pire qu'un système qui ne répond pas.
• Qui intervient quand une connexion se rompt ou qu'un accès expire, et en combien de temps.
• Ce qui se passe si la personne qui s'en occupe est absente. Cela vaut pour le prestataire comme pour vous.

Standard et sur mesure peuvent coexister

Le choix est rarement tranché. La solution la plus stable garde en standard tout ce qui ne vous distingue pas et ne construit que la partie qui dépend de vous : vos sources, vos règles, la connexion à vos systèmes. Il convient aussi d'écrire dès le départ ce qui resterait à vous si vous changiez d'outil — les documents préparés, les instructions, les cas de test, les données recueillies — car c'est ce qui vous permet de changer d'avis sans repartir de zéro.

Ce que ce guide ne couvre pas

Il est ici question du choix entre ce qui est disponible et ce qui doit être construit, sur votre cas. Vous ne trouverez pas de classements de modèles ni de comparaisons générales entre produits : ils changent dans le temps et ne seraient pas comparables à votre travail. La distinction entre automatisation traditionnelle et intelligence artificielle, ainsi que les postes de coût pour entretenir un assistant dans le temps, sont traités à part.