Equio : une IA qui n’a pas le droit de rassurer à tort

Un propriétaire de chevaux voit une plante inconnue dans son pré. Il a son téléphone dans une main, une longe dans l’autre, du soleil sur l’écran et parfois deux barres de réseau. La question qu’il se pose est simple : est-ce que je laisse mon cheval brouter ici ? Toute l’application tient dans la qualité de la réponse à cette question, et dans le temps qu’elle met à arriver.

Equio est une application iOS et Android qui analyse une photo de plante et signale un risque potentiel de toxicité. J’en ai mené la réflexion produit, la conception des écrans, le développement, l’intégration de l’IA, les abonnements, les tests et la publication sur les deux stores.

Reconnaître une plante sur une photo est un problème largement résolu. Ce qui ne l’est pas, c’est de le faire sur une photo prise en marchant, à contre-jour, sur une plante mêlée à trois autres, par quelqu’un qui ne sait pas ce qu’il photographie — et qui prendra la réponse au sérieux.

Une IA de reconnaissance ne dit jamais « c’est une renoncule ». Elle dit « renoncule, avec tel degré de confiance ». Toute la conception du produit consiste à décider ce qu’on fait de ce degré de confiance, et c’est une décision de produit, pas de modèle.

C’est la décision qui a cadré tout le reste. Une application comme celle-ci peut se tromper de deux façons, et il faut choisir laquelle on préfère :

• Signaler un danger qui n’existe pas. L’utilisateur déplace son cheval pour rien, est agacé, et perd un peu confiance dans l’application.
• Passer à côté d’un danger réel. L’utilisateur laisse brouter en confiance, parce que l’application le lui a dit.

Ces deux erreurs sont mesurées de la même façon par un modèle. Elles n’ont rien à voir dans la vraie vie. Huit ans passés sur des logiciels hospitaliers et aéronautiques laissent au moins ce réflexe : dans un domaine où une erreur a des conséquences physiques, on choisit délibérément de se tromper du côté le moins grave, et on l’assume dans l’interface.

Concrètement, l’application ne délivre pas de certificat d’innocuité. Quand la confiance est insuffisante, elle ne devine pas : elle le dit, et propose de reprendre la photo autrement. Un « je ne sais pas » explicite est une réponse utile ; une réponse fausse formulée avec assurance ne l’est jamais.

Une IA qui se tait quand elle doute inspire plus confiance qu’une IA qui répond toujours. C’est contre-intuitif en démonstration, évident sur le terrain.

La fonction d’analyse est ce qu’on montre ; elle est loin d’être ce qui prend le plus de temps. Une application publiable demande tout ce qui l’entoure : les profils des chevaux, l’historique des analyses, les comptes, l’abonnement, les écrans d’erreur, les cas sans réseau, les mentions légales.

C’est le graphique que je montre le plus souvent en premier rendez-vous. Quand quelqu’un arrive avec « une application simple, juste une photo et un résultat », ces 65 % du bas sont la partie qu’il n’a pas encore comptée — et c’est exactement la même proportion sur un projet à 15 000 € que sur un projet à 60 000 €.

Equio fonctionne par abonnement. Gérer des abonnements sur mobile est une de ces tâches qui paraissent triviales et ne le sont jamais : deux magasins aux règles différentes, des périodes d’essai, des restaurations d’achat sur un nouveau téléphone, des remboursements, des reçus à vérifier côté serveur pour qu’on ne puisse pas s’offrir l’abonnement en modifiant l’application.

J’ai utilisé RevenueCat plutôt que de l’écrire à la main. Ce n’est pas une économie de développement — c’est une économie de bugs sur les six mois qui suivent, sur des cas qu’on ne peut pas tous reproduire en test. Savoir quoi ne pas développer soi-même fait partie du travail : chaque brique achetée est une brique qu’on ne maintiendra pas.

Publier une application n’est pas un bouton. C’est un dossier : fiches descriptives dans chaque langue, captures d’écran aux formats de chaque appareil, icône, politique de confidentialité en ligne et accessible, déclaration précise des données collectées, et comptes développeur créés au nom du client, jamais au mien.

Les applications qui touchent de près ou de loin à la santé — même animale — sont examinées avec attention. La règle qui m’a guidée est la même que celle de la conception : ne rien promettre que l’application ne tienne. Une fiche qui annonce un diagnostic là où l’application signale un risque est un refus assuré, et un refus coûte deux semaines.

• Décider du comportement en cas de doute avant d’écrire une ligne de code. C’est une décision de produit ; la reporter à la fin donne une interface qui ment poliment.
• Tester dehors, pas au bureau. Le soleil, les gants, le réseau faible et la main occupée changent plus l’interface que n’importe quelle maquette.
• Compter la publication dans le projet. Fiches, visuels, confidentialité, comptes : c’est du travail, et il tombe au pire moment.
• Acheter les briques standard. Abonnements, authentification, envoi d’e-mails : ce qui existe et fonctionne se paie moins cher que ce qu’on maintient.

Equio, VetSafe et Ellyo sont publiées sur l’App Store et Google Play, et suivies depuis. Si vous avez un projet d’application et que vous voulez savoir ce qu’il demanderait — pas seulement en développement, mais en conception, en tests et en publication — décrivez-le en quelques lignes : je vous réponds sous 48 heures.