Douze idées d'IA sur la table : laquelle vaut vraiment le coup ?

Vous avez une liste. Elle fait douze lignes, parfois trente. Elle est née d'un comité de direction, d'un séminaire, ou de la veille d'un responsable métier : chatbot support, maintenance prédictive, analyse des appels d'offres, tri automatique des candidatures.

La question n'est pas de savoir si ces idées sont bonnes. C'est de savoir laquelle fera gagner de l'argent, et en combien de temps.

Pourquoi la liste ne se tranche pas en réunion

Trois raisons reviennent systématiquement.

Les idées ne sont pas comparables entre elles. « Réduire les délais de réponse client » et « anticiper les pannes machine » ne se mesurent pas dans la même unité, ne mobilisent pas les mêmes données, et n'ont pas le même horizon de retour. Les mettre côte à côte dans un tableau ne les rend pas comparables pour autant.

Personne dans la salle ne sait ce que coûte réellement chaque option. Le coût de développement est la partie visible. Ce qui se voit moins : le coût récurrent d'exploitation, la reprise de données, le temps que vos équipes devront y consacrer, et la maintenance quand le modèle dérive.

La faisabilité est supposée, pas vérifiée. « On a les données » est l'affirmation la plus fréquente et la moins vérifiée des projets IA. Dans les faits, les données existent souvent — mais dispersées dans sept systèmes, documentées nulle part, ou trop récentes pour le cas d'usage visé.

Ce qu'un arbitrage sérieux exige

Pour départager deux cas d'usage, il faut trois informations que la plupart des entreprises n'ont pas sous la main :

1. L'état réel de la matière première. Quelles sources, quelle qualité, quelle accessibilité. C'est ce qui détermine si un projet démarre dans trois semaines ou dans six mois.
2. Le gain chiffré, pas estimé. Combien d'heures économisées, combien de marge récupérée, sur quel volume. Avec l'hypothèse écrite noir sur blanc, pour qu'elle soit discutable.
3. Le coût complet sur la durée. Développement, exploitation, montée de version. Un projet rentable la première année et déficitaire la troisième n'est pas un projet rentable.

Croisez les trois, et la liste de douze lignes se réduit d'elle-même. Généralement à trois ou quatre candidats sérieux, dont un ou deux évidents.

Le tri le plus utile est celui qui élimine

Dans nos diagnostics, la conclusion la plus fréquemment utile n'est pas « faites ceci ». C'est « ne faites pas cela, et voici pourquoi ».

Un cas d'usage écarté avant d'avoir consommé un budget de développement, c'est un investissement évité. Et l'inventaire des données produit au passage reste valable : il servira au projet suivant, celui qui, lui, est mûr.

Une démarche de diagnostic peut parfaitement conclure « pas d'IA sur ce sujet cette année ». C'est un résultat, pas un échec.

Par où commencer concrètement

Avant tout outil et toute technologie, une question : quelle décision de votre entreprise voulez-vous améliorer ? Pas quel processus automatiser — quelle décision. Une décision prise trop tard, trop souvent à l'aveugle, ou trop coûteuse à instruire.

Répondez à celle-là, et le cas d'usage se dessine presque tout seul. Le reste — les données, l'architecture, le modèle — n'est que de l'ingénierie.

C'est exactement l'objet du Diag Data IA : partir de vos décisions, cartographier ce dont vous disposez, et ressortir avec trois à cinq cas chiffrés et une feuille de route à 12-18 mois. Financé à 40 % par Bpifrance.