Soutenir une thèse en IA et déployer en entreprise

Une thèse en IA sert, quand on déploie de l’IA générative en entreprise, moins par son sujet que par la discipline de mesure qu’elle impose : ne jamais conclure sans protocole. C’est la réponse courte à une question qu’on me pose souvent.

J’ai soutenu ma thèse de doctorat le 26 septembre 2025 à l’Université Grenoble Alpes, en signal, image, parole et télécommunications. Elle portait sur des méthodes d’apprentissage profond pour l’identification et la quantification en temps réel de particules en suspension dans l’air, par imagerie. La notice nationale de la thèse, sous mon nom académique Anandaramane Candassamy, confirme le sujet et la soutenance.

La question qui revient est simple : à quoi ça sert, quand on déploie de l’IA générative en entreprise. C’est une question légitime, parce que le sujet de la thèse n’a aucun rapport direct avec les modèles de langage.

Par transfert, j’entends ici ce qui, dans une formation par la recherche, reste utilisable une fois sorti du domaine étudié : des façons de raisonner, de mesurer et de douter, plutôt que des connaissances sur un objet précis.

Un doctorat ne garantit pas à lui seul la capacité à conduire un projet, à arbitrer un budget ou à faire adopter un outil dans une organisation. Commençons par là, parce que c’est la partie honnête.

Il n’apprend pas non plus à arbitrer un budget, ni à travailler sous la contrainte d’une date. Sur ces terrains, une expérience de production peut être plus utile que le seul titre de docteur, et il n’y a rien de vexant à le dire.

J’ai vu des thésards excellents produire des systèmes inutilisables, pour des raisons qui n’avaient rien à voir avec leur niveau technique.

La recherche apporte des habitudes de lecture critique, de mesure et de reconnaissance des limites, qui deviennent utiles en entreprise lorsqu’elles servent une décision concrète et vérifiable.

• Savoir ce qu’un chiffre mesure. Une publication annonce un gain sur un banc d’essai. La question réflexe devient : sur quelles données, contre quelle référence, avec quelle variance.
• Reconnaître une limite structurelle. Certains problèmes ne se règlent pas par plus de données ou un modèle plus gros. Savoir lesquels évite des trimestres perdus.
• Distinguer un progrès d’un réglage. Beaucoup d’annonces décrivent une optimisation qui ne transfère pas hors de son contexte d’évaluation.
• Construire un protocole. C’est exactement ce qu’est un jeu de tests métier : un protocole d’évaluation, avec ses biais assumés.
• Dire « on ne sait pas ». La recherche l’enseigne par la pratique. En entreprise, c’est une phrase rare et précieuse.

Le transfert le plus utile de la recherche vers le déploiement est l’exigence de mesure : trois ans passés à justifier chaque chiffre devant un jury laissent l’habitude de ne pas conclure sans protocole. Ce n’est pas un savoir sur les modèles, c’est un réflexe.

Appliqué au déploiement, cela donne le réflexe que je décris dans presque tous mes articles : constituer un jeu de tests avant de développer, le rejouer à chaque changement, refuser de trancher à l’impression. Ce n’est pas une méthode que j’ai apprise en entreprise ; c’est une déformation professionnelle qui s’est trouvée utile. Elle est formalisée dans l’évaluation continue, le chaînon manquant.

L’autre transfert est la lecture critique. Le volume d’annonces dans ce domaine est tel que la capacité à écarter rapidement ce qui ne tiendra pas est devenue un avantage économique direct. La grille que j’applique est détaillée dans comment lire une annonce de benchmark.

Commencer par le protocole d’évaluation permet d’expliciter le résultat attendu avant de comparer les modèles, puis de vérifier les changements avec les mêmes critères métier.

Je passe plus de temps que la moyenne sur le protocole d’évaluation, et moins sur le choix du modèle. C’est contre-intuitif quand on arrive, et c’est ce qui fait gagner du temps au troisième mois.

Transformer « est-ce que ce système est bon ? » en question mesurable revient à construire un protocole sur une question mal définie : c’est la compétence qui se transfère le mieux, et elle est rare en entreprise. Elle porte sur la démarche, jamais sur le domaine.

La question posée en entreprise ressemble à une question de recherche. Elle n’est pas mesurable telle quelle. Le travail consiste à la décomposer, en quatre étapes :

1. Décomposer en questions vérifiables. « Le système cite-t-il le bon document ? », « Le montant est-il exact ? », « Refuse-t-il quand l’information manque ? ».
2. Définir ce qui compte comme succès. Pour chaque question, ce qu’une réponse acceptable doit contenir, validé par quelqu’un du métier.
3. Construire l’échantillon. Des cas réels, dont une part de cas limites, et non les seuls cas de démonstration.
4. Assumer les biais. Écrire ce que l’échantillon ne couvre pas, pour que personne ne conclue au-delà.

C’est exactement ce qu’un jeu de tests formalise, et c’est pourquoi je le pose en premier livrable. La méthode figure dans construire un jeu de tests en une journée.

Je ne suis pas resté au laboratoire parce que la question qui m’intéresse n’est pas de savoir jusqu’où un modèle peut aller, mais ce qui se passe quand on le met entre les mains de gens qui ont un travail à faire. Cette question ne se traite pas depuis un laboratoire.

Elle se traite en s’installant dans l’organisation, en regardant le travail se faire, et en construisant avec ceux qui le font. C’est la définition du métier que j’exerce, et j’en parle dans Forward Deployed Engineer : le métier, pas le titre. Les différentes facettes de ce travail sont présentées sur la page métiers.

La recherche n’apprend ni à arbitrer sous contrainte de temps, ni à écarter un cas d’usage, ni à tenir un système en exploitation : ces trois compétences s’acquièrent sur le terrain et rien ne les remplace. Elles sont pourtant celles qui décident de l’utilité d’une intervention.

Un travail de recherche autorise l’exhaustivité et récompense la profondeur. Une mission impose de trancher avec une information incomplète, de renoncer à ce qui n’aboutira pas, et de livrer quelque chose qui tienne sans son auteur.

Le renoncement est le plus contre-intuitif pour qui vient de la recherche, où un sujet difficile est une raison de persévérer. En entreprise, c’est souvent une raison d’arrêter, comme le montre combien de cas d’usage il faut abandonner.

La dernière exigence, livrer quelque chose qui tienne sans son auteur, est la plus étrangère à la formation par la recherche. Elle est développée dans les trois gestes qui font tenir un système.

Il ne faut pas faire du doctorat un critère de recrutement : ce qui distingue un profil utile est sa capacité à écarter un cas d’usage et à construire une mesure, et le diplôme seul ne permet pas de le vérifier. Ces compétences doivent être éprouvées sur un cas concret.

J’ai rencontré d’excellents ingénieurs sans formation par la recherche qui possédaient les deux, et des docteurs qui n’avaient jamais eu à renoncer à un sujet.

Les questions qui les révèlent en entretien sont simples : quel projet avez-vous arrêté et pourquoi, et comment sauriez-vous que ce système fonctionne. Elles sont détaillées dans recruter un profil IA : ce qu’il faut chercher.

La compétence de mesure, elle, s’enseigne aussi en dehors d’un doctorat : c’est l’un des axes que je travaille en formation IA avec des équipes qui n’ont pas de formation par la recherche.

Les erreurs fréquentes d’un profil issu de la recherche en entreprise sont de viser l’exhaustivité, de privilégier le modèle sur l’usage, de différer la livraison jusqu’à la certitude et de parler le langage du laboratoire à une direction. Toutes tiennent au décalage entre deux systèmes de récompense.

• Viser l’exhaustivité. Couvrir tous les cas avant de livrer, quand l’organisation a besoin d’un périmètre étroit qui fonctionne.
• Optimiser le modèle. Chercher le meilleur score quand le problème est dans le corpus ou l’intégration.
• Attendre la certitude. Une mission impose de trancher avec une information incomplète, et de l’assumer.
• Parler en métriques de publication. Une direction attend une décision et ses conséquences, pas une courbe.