Intégrer de l’IA dans une application : utile ou gadget ?

La question m’est posée à presque chaque premier rendez-vous, et rarement dans ce sens-là. On me demande généralement « est-ce qu’on peut mettre de l’IA ? ». La réponse est oui, toujours. La bonne question est ailleurs : qu’est-ce qu’elle remplace, et combien coûte-t-elle à faire tourner ?

Une fonctionnalité d’IA est utile quand elle supprime un travail que quelqu’un fait aujourd’hui à la main, mal ou lentement. Elle est un gadget quand elle ajoute une possibilité dont personne n’avait exprimé le besoin.

Ce test paraît trivial. Il élimine pourtant la majorité des demandes, à commencer par la plus fréquente : l’assistant conversationnel posé sur un site vitrine. Personne ne fait ce travail aujourd’hui, donc l’assistant n’en supprime aucun ; il déplace le sommaire du site dans une fenêtre de discussion, en moins fiable.

Les trois formes qui tiennent

• Lire ce que l’utilisateur ne veut pas saisir. Une photo, une facture, un devis, un compte rendu : le modèle extrait les informations, l’utilisateur corrige. On remplace dix champs de formulaire par une vérification.
• Trier ce qui arrive en trop grand nombre. Classer des demandes entrantes, repérer les doublons, orienter vers le bon service. Le gain se mesure dès la première semaine, en heures.
• Rédiger un premier jet. Une réponse type, un résumé, une description de produit. Jamais publié tel quel : le gain n’est pas d’éviter la relecture, c’est d’éviter la page blanche.

Une fonctionnalité ordinaire se paie une fois. Elle est développée, elle est livrée, elle tourne : qu’elle serve dix fois ou dix mille fois par mois ne change rien à la facture. Une fonctionnalité d’IA ne fonctionne pas ainsi. Chaque utilisation appelle un service qui se facture à l’usage — au volume de texte traité, à l’image analysée, à la minute d’audio.

La conséquence est contre-intuitive et il faut la regarder en face : plus la fonctionnalité rencontre son public, plus elle coûte cher. Un succès inattendu sur une fonction classique est une bonne nouvelle sans réserve ; sur une fonction d’IA, c’est une bonne nouvelle assortie d’une facture.

Le calcul à faire avant de décider

Il tient en une ligne : coût d’un appel × nombre d’appels par utilisateur et par mois × nombre d’utilisateurs. Les tarifs des fournisseurs sont publics et se vérifient en dix minutes ; le nombre d’appels par utilisateur, c’est vous qui l’estimez, et c’est le seul terme qui compte vraiment.

Si ce montant mensuel dépasse ce que l’utilisateur vous rapporte, la fonctionnalité n’est pas un atout, c’est une fuite. C’est exactement pour cela que beaucoup d’applications qui embarquent de l’IA fonctionnent par abonnement plutôt qu’à l’achat unique : il faut un revenu récurrent pour couvrir une charge récurrente.

• Posez un plafond dès la première version. Un quota par utilisateur, une limite mensuelle globale, une alerte au-delà d’un seuil. Sans cela, une boucle défectueuse ou un usage automatisé consomme un budget entier en une nuit.
• Mesurez le coût réel par utilisateur au bout d’un mois de production. Les estimations d’avant-lancement se trompent, toujours dans le même sens.
• Gardez la possibilité de changer de fournisseur. Isolez l’appel au modèle derrière une seule fonction de votre code. C’est une demi-journée de travail qui vous laisse libre le jour où les tarifs bougent — et ils bougent.

Appeler un modèle est simple : quelques lignes, une clé, une réponse. Si le devis s’arrêtait là, une fonctionnalité d’IA coûterait moins cher qu’un formulaire de contact. Ce n’est pas le cas, et l’écart est celui que montre la figure ci-dessus.

Ce qui coûte, c’est tout ce qu’il faut construire pour le cas où la réponse est fausse. Un modèle se trompe. Pas souvent, pas absurdement, mais il se trompe — et il se trompe avec assurance, ce qui est bien pire qu’une erreur visible.

• Décider ce que l’application fait quand elle n’est pas sûre. C’est une décision de produit, pas une décision technique, et elle se prend avant d’écrire une ligne de code. Sur Equio, qui évalue la toxicité d’une plante pour un cheval, c’est la décision qui a structuré tout le reste : ne jamais rassurer à tort.
• Vérifier ce qui peut l’être. Un montant extrait d’une facture se recoupe avec le total. Une référence produit se vérifie dans le catalogue. Tout ce qui se contrôle sans le modèle doit se contrôler sans le modèle.
• Prévoir le chemin de repli. Que se passe-t-il si le service est indisponible, lent, ou refuse la demande ? Une application dont la fonction principale s’arrête parce qu’un fournisseur tiers est en panne n’est pas terminée.
• Garder l’humain aux commandes quand l’enjeu est réel. Proposer, ne pas décider. Un premier jet à valider plutôt qu’un envoi automatique. C’est ce qui rend la fonctionnalité acceptable à ceux qui l’utilisent.

Une IA qui a raison neuf fois sur dix est une excellente IA. C’est aussi, sans garde-fous, une fonctionnalité qui produit une erreur par jour dans une application utilisée dix fois par jour.

Utiliser un modèle en ligne signifie envoyer quelque chose à un tiers. Selon ce qu’on envoie, cela demande d’être regardé de près — surtout s’il s’agit de données de vos clients, de documents internes ou d’informations relatives à des personnes.

• Savoir ce qui sort. Écrivez la liste de ce que l’application transmet, champ par champ. Souvent, une partie n’est pas nécessaire au traitement et peut simplement ne pas partir.
• Vérifier l’engagement du fournisseur sur la conservation des contenus envoyés et sur leur réutilisation pour entraîner ses modèles. Les offres professionnelles et les offres grand public ne disent pas la même chose.
• Informer les utilisateurs. Un traitement automatisé opéré par un tiers a sa place dans la politique de confidentialité, et il se déclare comme tel dans les fiches des magasins d’applications.

• Quelle tâche disparaît, et pour qui ? Si la réponse est « ça fait moderne », c’est un gadget. Si la réponse est « le secrétariat ne ressaisit plus les bons de commande », c’est un projet.
• Que se passe-t-il quand le modèle se trompe ? Si l’utilisateur s’en aperçoit et corrige, le risque est acceptable. Si personne ne s’en aperçoit, il faut soit vérifier, soit renoncer.
• Combien coûte un utilisateur actif par mois ? Si vous ne savez pas répondre, le calcul se fait maintenant. C’est vingt minutes de travail, et cela sauve parfois un modèle économique entier.

Une dernière chose, qui rassure rarement mais qui fait gagner du temps : l’IA est presque toujours la dernière fonctionnalité à construire, pas la première. Une application qui fonctionne sans elle peut la recevoir plus tard ; une application construite autour d’elle ne peut plus s’en passer le jour où le fournisseur change ses tarifs.

Si vous avez une idée de fonctionnalité et que vous voulez savoir de quel côté elle tombe — et ce qu’elle coûterait par mois une fois en service — décrivez-la en quelques lignes. Je réponds sous 48 heures, y compris quand la réponse est que ça n’en vaut pas la peine.