Optimiser trop tôt peut tuer l'invention

« Ça ne passera jamais en production. »

Trop cher. Trop lent. Trop complexe. Le composant n’est pas adapté. L’algorithme demande trop de ressources. L’architecture ne tiendra jamais à l’échelle.

Le plus gênant, c’est que toutes ces objections peuvent être parfaitement justes.

Simplement, on les pose parfois beaucoup trop tôt.

En R&D, il arrive qu’une idée soit abandonnée non pas parce qu’elle ne fonctionne pas, mais parce qu’on lui demande déjà de respecter les contraintes d’un produit qui n’existe pas encore.

Toutes les questions ne se posent pas au même moment #

Une expérience peut parfois n’avoir qu’un seul objectif : savoir si un phénomène existe.

Dans ce cas, peu importe que le premier montage soit encombrant, que le capteur coûte dix fois le prix acceptable pour le produit final ou que le calcul prenne trois secondes alors qu’il devra un jour être réalisé en temps réel.

Ce que l’on cherche à savoir à cet instant est beaucoup plus simple : est-ce que ça marche ?

Si la réponse est non, on a appris quelque chose.

Si la réponse est oui, d’autres questions arrivent naturellement.

Peut-on obtenir le même résultat avec un capteur moins cher ? Réduire le temps de calcul ? Miniaturiser le montage ? Diminuer sa consommation ? Le rendre reproductible ?

Ces questions sont importantes. Certaines finiront même par décider de la viabilité du produit.

Mais elles n’ont pas forcément besoin d’être résolues pendant la première expérience.

Le prototype n’est pas le produit #

Prenons un algorithme qui nécessite, pour les premiers essais, un ordinateur puissant alors que le produit final devra fonctionner sur un système embarqué.

On peut regarder la consommation de ressources et conclure immédiatement que l’approche n’est pas viable.

Ou on peut commencer par vérifier qu’elle produit effectivement l’information recherchée.

Si elle n’apporte rien, le problème est réglé.

Si elle fonctionne particulièrement bien, alors il devient intéressant de chercher comment conserver ce résultat avec moins de ressources.

Peut-être faudra-t-il changer d’algorithme. Peut-être déplacer certains traitements. Peut-être utiliser une autre représentation des données ou revoir complètement l’architecture.

C’est justement le travail qui vient après.

Le prototype initial n’avait pas besoin de contenir toutes ces réponses. Il devait permettre de savoir si la piste méritait qu’on continue à poser des questions.

C’est une distinction qui paraît évidente sur le papier et qui l’est beaucoup moins dans un projet réel.

Nos bonnes pratiques peuvent nous jouer des tours #

Les contraintes industrielles ne sont d’ailleurs pas les seules à pouvoir fermer une piste trop tôt.

Nos habitudes d’ingénieurs peuvent faire exactement la même chose.

On veut naturellement du code propre, une architecture robuste, des mesures reproductibles, de la sécurité, de la maintenabilité. Et lorsque le produit est concerné par des exigences réglementaires, on sait qu’elles devront également être prises en compte.

Tout cela est parfaitement légitime.

Le problème apparaît lorsque le coût nécessaire pour tester une idée devient presque aussi important que celui nécessaire pour commencer à en faire un produit.

On hésite alors à essayer quelque chose d’un peu étrange parce qu’il faudrait d’abord l’intégrer proprement à l’existant.

On écarte un composant parce qu’il est trop cher alors qu’il aurait permis de vérifier une hypothèse en deux heures.

On renonce à un algorithme parce qu’il est beaucoup trop lent dans sa première version.

Petit à petit, on finit surtout par expérimenter ce dont on pense déjà que cela va fonctionner.

Et pour de la R&D, c’est un peu dommage.

Un prototype peut avoir le droit d’être mauvais #

Mauvais au sens où on l’entendrait pour un produit.

Il peut avoir des câbles partout. Utiliser un composant hors de prix. Nécessiter une manipulation manuelle. Mettre plusieurs secondes à calculer quelque chose. Être incapable de fonctionner plus de vingt minutes sans redémarrer.

Ce n’est pas grave si aucun de ces points n’est la question à laquelle l’expérience cherche à répondre.

En revanche, il faut savoir pourquoi on accepte ces défauts.

Et les garder en tête.

Parce qu’une fois le principe validé, ils redeviennent des problèmes à résoudre.

C’est là que l’ordre des questions devient important.

D’abord : est-ce possible ?

Ensuite : est-ce suffisamment intéressant pour continuer ?

Et si c’est le cas : comment en faire quelque chose qui fonctionne réellement dans les contraintes du produit ?

Mélanger ces étapes revient parfois à industrialiser une hypothèse.

Savoir ce que l’on cherche à conserver #

C’est aussi à ce moment que l’optimisation devient beaucoup plus intéressante.

On ne cherche plus vaguement à « faire mieux ».

On sait ce qui fonctionne et ce que l’on veut préserver.

Le capteur coûte trop cher ? Essayons-en un autre et vérifions que l’information reste exploitable.

Le calcul prend trois secondes ? Cherchons à le réduire sans perdre ce qui faisait l’intérêt du résultat.

Le montage est trop complexe ? Simplifions-le et regardons à quel moment ses performances commencent réellement à se dégrader.

Chaque contrainte que l’on réintroduit devient alors une nouvelle expérience.

On ne demande plus à l’idée de prouver immédiatement qu’elle peut devenir un produit.

On cherche progressivement jusqu’où on peut la contraindre sans perdre ce qui la rendait intéressante au départ.

Et c’est souvent là que commence réellement le travail d’ingénierie.

Après, évidemment, il faudra revenir au monde réel. Parce que l’excès inverse existe aussi : à force d’expérimenter sans jamais réintroduire les contraintes du produit, on finit par fabriquer de très beaux démonstrateurs — dont on ne sait pas quoi faire.

---

Perspective 06 — lundi prochain : À force de garder toutes les options ouvertes, on finit par ne plus avancer.