Preuves de concept

Tiens, si on payait une blinde pour que des mecs développent un truc nébuleux qui n’a aucune chance de passer un jour en production ?

(tout le monde)

Ce n'est pas la stratégie d’Elon Musk.
Elon Musk est né riche.
Elon Musk a une conception de la vie étrange.
Elon Musk appelle ses enfants avec des noms étranges …
Mais Elon Musk a compris l’importance de bien construire ses POC.

Car il construit des RPoC.
On vous explique ce que c’est.
Sans vous parler d’Elon Musk.

• résumé

  On parle ici de faisabilité technique : data, algorithmes et informatique.
  
  Un POC sert à s’assurer qu’un service ou un outil est faisable. S’il ne l’est pas, autant perdre le moins de temps possible.

  
  Un POC robuste doit donc identifier les points bloquants et les attaquer frontalement. Le but n’est pas de se rassurer en se disant que tout ira bien (=la pensée positive performatrice ne marche jamais en ingénierie). Le but est d’identifier les points bloquants et les attaquer frontalement.

Contexte

POC ? Proof of concept, soit preuve de concept.

C’est une sorte de prototype qui démontre par l’exemple qu’on peut construire quelque chose : objet, service, recette.

Faire un POC dans la data/IA, c'est souvent une histoire étonnante. Vous savez de quoi je parle. Un peu comme si on faisait ses gammes avec un quatuor cor et hautbois dans un salon feutré de Versailles, tout en caressant le secret rêve de s’enfuir dans un champ boueux pour sept heures de dubstep sous acide. Vous avez l’idée.

De l’intérêt de payer cher pour des trucs inutiles

Les POC sont souvent des échecs programmés.

Tout le monde veut se lancer et expérimenter la nouvelle technologie du moment. Le BigData au début des années 2010s, et à partir de 2016, la longue liste des trucs semi-compréhensibles comme l'apprentissage automatique puis des réseaux de neurones, avec la folle aventure de la blockchain en cours de route. Aujourd’hui, le monde n’a d’yeux que pour les LLMs et son porte drapeau, ChatGPT. 

C’est humain mais c’est idiot.

Vous me direz que c’est le principe de la R&D (recherche et développement). Il faut essayer. Tenter des trucs. Se lancer. Et vous auriez raison !

Je vous répondrais tout de même que je n’ai jamais vu, en entreprise, un projet R&D qui n’était pas assez rapidement orienté vers la production. Et ça se comprend aisément. Tout le monde n’est pas le CNRS ou encore Google. Les nouveaux maîtres du monde appellent d’ailleurs ces projets des moonshots. Ils ont une filiale totalement centrée sur ces sujets très exploratoires - X Development LLC, ex Google X.  

Mener des projets de R&D est difficile. Surtout lorsque les technologies sont nouvelles et complexes. L’innovation, ça coûte cher et c’est risqué. Tout le monde n’a pas les poches aussi profondes, alors comment on fait ?

La recette magique

Puisqu’il faut avancer, il faut être pragmatique. Identifier les risques. Penser aux usages et à la production dès le départ. Ces quelques règles s’appliquent bien à l’innovation numérique ou, pour le dire vite et avec les mots du jour, à l’intelligence artificielle.

Rappelons en passant que “tout problème pour lequel aucune solution algorithmique n’est connue, relève a priori de l’intelligence artificielle”.

Par algorithme, il faut entendre ici toute suite d’opérations ordonnées, bien définies, exécutables sur un ordinateur actuel et qui permet d’arriver à la solution en un temps raisonnable (de l’ordre de la minute ou de l’heure). Ainsi, on ne connaı̂t pas d’algorithme pour jouer aux échecs, bien que ce jeu ne comporte qu’un nombre fini de situations, mais les étudier toutes demanderait des millénaires. De même, il n’existe pas d’algorithme pour effectuer un diagnostic médical, résumer un texte ou le traduire dans une langue étrangère.

Jean-Louis Laurière, Intelligence artificielle : Résolutions de problèmes par l'homme et la machine (1985) 

Le secret, c’est d’ouvrir les yeux et d’affronter le réel. Ne pas cacher les problèmes sous le tapis en feignant de ne pas les voir, ou en prétextant qu'on les réglera plus tard. Non, il faut avancer directement dans le concret, et s’en donner les moyens.

Illusion v Robustesse

Nommons les choses.

Le POC qui ne sert à rien, je l’appelle POI, pour Proof of Illusion.
Le POC qui fait avancer les choses, je l’appelle RPoC, pour Robust Proof of Concept. Et pas Air POC, n’est-ce pas.

C’est moche ? Pas grave.
Si les POI sont légions, les RPoC sont rares.

Viser la difficulté

Un POI tente de contourner la difficulté et de retarder l’échec. On se paie le luxe de résoudre un sous-problème accessoire ou incomplet, tout en sachant pertinemment que c'est de la poudre aux yeux. Le réel, c’est ce qui résiste. C’est vrai dans la vie. C’est d’autant plus vrai en traitement de données et en intelligence artificielle : size matters.

Mener un RPoC, c’est choisir la face nord d’une ascension. Celle qui est tout le temps gelée. Celle qui pique. Il faut être intransigeant et impitoyable pour s'attaquer frontalement aux vrais problèmes. La démarche gagnante, sur des problèmes de ce type, c’est toujours de choisir la solution offensive en première approche. Et de bien ouvrir les yeux.

La traduction opérationnelle consiste à se frotter à la complexité des données (formats, volume, qualité) et des algorithmes. On peut se faire la main sur des petits cas, pour mieux connaître le problème, mais il ne faut pas s’attendre à conserver les premières solutions.

Le peuple réclame des exemples 

Ex1. Lire plein de documents.

Vous voulez extraire des informations structurées de 100000 textes dans des formats différents, comme des contrats ou des documents officiels ? La difficulté majeure consiste à gérer l’hétérogénéité des formats. Les informations intéressantes sont disséminées un peu partout, sans schéma directeur commun. Il faut donc trouver une méthode pour traiter le plus de formats de documents possible, en acceptant d’être moins précis sur chaque document : être générique plutôt que spécifique, être souvent moyen plutôt que parfois excellent. 

Un POI essaiera de traiter d’abord 100 documents, de manière consciencieuse, à partir de méthodes spécifiques aux formats observés. Le projet donnera une impression de réussite en construisant un indicateur de performance couverture / précision qui avoisinera les 70-80%. Il échouera à passer à l’échelle sur les 99900 autres formats. Le POI ne traitera pas le vrai problème.

Un RPoC s’attaquera directement au corpus de 100000 documents avec des méthodes adaptées, probablement des modèles de langages ou des outils spécialisés en NLP décrits dans des articles scientifiques récents. Il n’est pas évident que ça fonctionne, mais au moins l’échec sera rapide.

Ex2. Bien charger les bateaux.

Vous voulez déplacer des milliers de conteneurs d’Asie vers l’Europe ? Ça se fait habituellement avec de gros porte-conteneurs sur lesquels on empile jusqu’à 20000 conteneurs façon Tetris. La difficulté majeure, c’est de maîtriser l’empilement des conteneurs pour faciliter le déchargement. Il se trouve que ce problème redoutable est bien connu des mathématiciens et fait partie d’une catégorie de problèmes vraiment difficiles. On ne connaît pas de méthode de résolution efficace générique pour ce type de problèmes de combinatoire, malheureusement. Par contre, on connaît le critère principal qui pilote la difficulté ! C’est le nombre de conteneurs, tout simplement.

Un POI essaiera de résoudre un petit problème complet (n=100, n=1000) en concentrant son énergie sur ce qui est faisable : la modélisation des contraintes, une description fine du bateau, le benchmarking de solutions adaptées pour les petits cas, voire la reprise de code de résolution pour des cas plus petits. L’hypothèse principale suppose qu’une solution pour n=100 fonctionnera pour n=10000. C’est faux. 

Un RPoC s’attaquera au gros problème (n=20000) quitte à faire des hypothèses simplificatrices temporaires. En effet, l’horreur qui nous attend, tapie dans l’ombre, est l’explosion combinatoire. Il n’est pas nécessaire de rentrer dans la théorie de la complexité algorithmique pour sentir qu’une progression exponentielle (ou bien pire, factorielle !) fera exploser le temps de calcul et la consommation mémoire. Il ne faut pas affronter l’explosion combinatoire de face. Il faut la contourner. Hors de question de s’appuyer sur la puissance de calcul seule, il va falloir être malin.

Ex3. Classer efficacement les opérations bancaires.

Vous voulez classer automatiquement les opérations bancaires de vos clients selon les dizaines de postes de dépense : restaurants, assurances, alimentaires, locations immobilières etc ? La difficulté majeure consiste à identifier la multitude des petites dépenses chez les petits commerçants : Amazon et Total, c’est facile. Le Café de la Poste de Cavaillon ou le coiffeur Chez Annie de Piriac, c’est plus difficile. Il faut donc séparer ce problème de classement en sous-problèmes partiels et construire des outils adaptés à l’hétérogénéité des informations observées dans les données brutes de paiement (libellés, montants, dates).

Un POI pourra essayer différentes méthodes sur l’ensemble des données, en essayant de se convaincre qu’il suffit de trouver les bons critères de détection humains, ou en exploitant une base d’apprentissage suffisamment grosse (=apprentissage automatique). Les performances stagneront, ou le système deviendra obèse. Ou une pluie de crapauds s’abattra sur vos dépôts git. 

Un RPoC s'attaquera au problème complet en procédant à une longue exploration des données. La clé est de reconnaître rapidement que ce problème peut être réglé par une approche graduelle, en ramenant le classement à une suite de sous-classements plus simples. Un traitement par étages. Il paraît improbable de traiter des dépenses communes des mastodontes (Amazon, Total, Orange), des opérations récurrentes et habituelles comme la foultitude de dépenses locales aléatoires. KISS et diviser pour mieux régner.

Pourquoi se compliquer la vie ?

Parce qu’on ne fait pas ce métier pour la facilité, au fond.

Et surtout, parce que si le problème s’avère trop difficile, ou impossible, la bonne stratégie est d’abandonner le plus rapidement possible. Viser l’échec le plus rapidement, donc. 

Comment ?

Pour construire un RPoC, il faut d’évidence pouvoir identifier les sujets techniques principaux. Ceux qui bloquent, ceux qui piquent. Il suffit d’un solide bagage technique en modélisation et en algorithmique, couplé à une volonté farouche de se prendre la tête sur des problèmes techniques incomplets ou mal posés.

Bref, rien ne remplace l’expérience. Comme dans plein de domaines, en fait. J’ajouterai qu’il est crucial de savoir ce qu’ont fait les grands anciens, en l'occurrence avoir une connaissance de l’histoire de l’intelligence artificielle. Et de l’informatique en général, ça ne fera pas de mal. Qui ne connaît pas l’histoire est condamné à la revivre, et à en arpenter les cul-de-sacs, comme disait Dédale.

La bonne nouvelle, oui !, c’est que tout s’apprend.
Peut-être pas en quelques semaines, ni en quelques mois.

Pourquoi ça fonctionne ?

Un échec en informatique ne coûte rien en matières premières.

L’informatique est spéciale. On change de paradigme. Comme le dit Gérard Berry, médaille d’or 2014 du CNRS, l’information intègre le schéma classique {matière, énergie, ondes}. L’ingénieur en informatique ne se préoccupe pas vraiment de matière, d’énergie ou d’ondes : il ne s’intéresse qu’à l’information. Ça peut sembler grandiloquent, mais ça change absolument tout.

Et c’est ce qui est fascinant dans le domaine informatique, et dans la partie “traitement de l’information” de l’intelligence artificielle. Nous avons cette liberté totale de se planter, de louper, de tout démolir pour mieux reconstruire. C'est un luxe que d'autres secteurs ne peuvent pas se permettre, comme l'ingénierie aérospatiale (sauf Space X). On tâtonne, on expérimente, et on voit ce que ça donne. Enfin, ça marche une fois qu’on a compris qu’on n’était pas forcé de  jeter son ordinateur quand un programme se plante.

Vous voulez innover ?
Echouez le plus vite possible.