Prototypage et (peut-être un) succès : l'importance de la R&D au sein d'un projet technique

J'écris cet article autant pour mes collègues que pour mes clients actuels ou futurs, car la R&D soulève souvent beaucoup de questions**. Comment arrivent les projets R&D ? Comment se lancer dans une problématique dont on n'a pas encore la réponse ? Comment limiter les coûts ? Il me semblait bon de faire un point sur notre méthodologie à Wanadev.

D'où viennent les idées de projet ?

Le plus souvent c'est de la rencontre entre expert métier et expert technique. L'expert métier ne sait pas forcément ce qu'il est techniquement possible de faire, mais il connaît le besoin. A l'inverse, l'expert technique peut sentir ce qu'il est possible de faire, mais ne réalise pas forcément comment l'exploiter.

Les meilleurs idées viennent de la discussion, de la rencontre et de l'enrichissement mutuel de 2 façons de penser différentes. C'est pourquoi il faut être au maximum à l'écoute, de ses équipes techniques, commerciales, de ses clients, de ses responsables ou de ses subordonnés, et essayer de comprendre leur chemin de pensée.

Comme dans toute création, rien ne vient jamais de nulle part. Il y a toujours une inspiration, un souvenir qui déclenche une réflexion qui amène sur le fameux Eurêka.

Nous vivons l'expérience quasiment à chaque projet chez Wanadev. Au fil de l'avancement, on se rend compte qu'un tout autre besoin métier pourrait être taclé efficacement par un développement spécifique. Et très souvent, nous avons de longues discussions qui débouchent sur des projets spin-off.

@ Les projets spin-off sont des projets en relation avec le besoin original qui ne ressemblent pas à ce qui a été imaginé au départ.

On a une idée ! Pas si vite...

Avoir une bonne idée, c'est très bien. Maintenant il faut y avancer de la façon la plus rationnelle possible. La première chose à quantifier, c'est la plus value métier d'une solution versus sa complexité. C'est un calcul basique, mais il nécessite d'avoir, encore une fois, une rencontre honnête entre les 2 visions, celle métier et celle technique.

2 pièges dans lesquels ne pas tomber :

Le défi technique :

Nous ingénieurs, adorons le challenge technique. C'est pourquoi notre métier est souvent notre passion, c'est de là que vient notre plus important travers. On parle ici de projet à plus-value, pas de passe-temps du dimanche. Donc exit les idées telles que : "Installer un capteur qui détecte la fin du rouleau de papier toilette" ou encore "développer un moteur de rendu 3D en PHP4".

L'idée buzzword :

C'est cette fois-ci le piège de l'expert métier : avoir entendu parler de nouvelles technologies et vouloir absolument les appliquer, quoi qu'il en coûte. Le device IoT qui fait du machine learning sur la blockchain, avec du big data visualisable en VR, n'a probablement pas lieu d'être.

La mise en oeuvre

Nous avons identifié une grosse plus-value métier si nous adressons ce problème. Quelles sont les étapes pour y arriver en limitant les risques ?

L'état de l'art

La première chose est de vérifier l'état de l'art. Est-ce que le sujet a déjà été traité ? Si oui, qu'est-il possible d'utiliser ? Projets open-source sous licence permissive, papiers de recherche, ou même encore techno propriétaire avec un coût raisonnable à l'utilisation... Très souvent des solutions partielles existent déjà ! Il faut être le plus exhaustif possible dans cette phase, pour éviter de réinventer la roue.

^ Très important également : il faut laisser son ego de côté. Se dire "je peux refaire cette partie, en mieux" juste pour se prouver à soi-même que l'on a le niveau, est un comportement à bannir.

Partir de l'état de l'art économise des centaines voire des milliers d'heures de développement inutiles. Donc autant passer beaucoup de temps d'analyse sur cette phase, plutôt que de perdre du temps à écrire du code.

Proof of concept (POC)

Le but d'un proof of concept, est de prouver que le projet est réalisable. Pour réaliser un POC, on va d'abord identifier des verrous techniques. C'est à dire éliminer tout ce qui est déjà résolu et qui ne nécessite pas de recherche, pour ne garder que les points d'interrogation qui nécessitent de la R&D. Et c'est là que l'instinct de l'expert technique rentre en jeu. Il faut "sentir", grâce à son expérience et à sa veille technique, la difficulté d'un point en particulier.

Le POC a pour but de déverrouiller ces verrous techniques. Il doit être le plus court possible en restant représentatif du problème. Une fois les verrous identifiés, on va écrire un cahier des charges "par étapes".

@ Pourquoi "par étapes" ? Il faut absolument essayer de résoudre le cas simple en premier, pour aller vers le cas le plus complexe. On aura économisé beaucoup de sang et de larmes en échouant sur un cas simple que sur un cas complexe.

Arrêtons nous un peu, et prenons un exemple : On veut faire un système web de reconnaissance de tickets de cinéma. Notre analyse de l'état de l'art nous fait pencher vers le machine learning, et plus précisément les CNN. Des détecteurs comme FasterRCNN ou encore YoloV3 ont eu beaucoup de succès récemment.

Le projet va alors être découpé pour faire un POC : la partie Web ne posera aucun problème, elle ne sera pas dans le POC. La partie machine learning est en revanche plus compliquée : il nous faudra un bon détecteur, et une grosse base de données de tickets. On sait aussi qu'il est difficile d'avoir 100% de réussite sur un détecteur, il faudra donc définir avec le commanditaire le seuil de qualité à atteindre. Tous ces verrous vont alors former le POC, qui va être d'arriver à lire un ticket de cinéma avec une confiance de X %.

On va alors commencer par le cas simple : des tickets scannés avec une haute qualité, sans bruit. Puis si on y arrive, on va rajouter la complexité : rajouter du grain à la photo, des tickets mal imprimés, mal cadrés, etc ... Jusqu'à ce que notre POC couvre le cas le plus complexe que l'on puisse trouver dans la réalité, et on pourra alors affirmer que le verrou technique est levé ! Si le POC est réalisé avec succès, on peut passer à la phase de développement. Si l'on a bien réalisé son travail d'étude préliminaire sur les verrous techniques, le développement est un jeu d'enfant !

Conclusion

La méthode présentée est un process qui s'est révélé efficace et économe. Notre leitmotiv est qu'un échec n'est pas important, tant qu'il arrive tôt dans la vie d'un projet. C'est pour cela que les phases préliminaires sont si importantes, car les moins sujettes à l'effet tunnel : développement long pour arriver à un résultat peu satisfaisant. En bref, une bonne R&D aura pour but d'éviter à tout prix de se lancer dans des chantiers inutiles, tout en gardant une certaine créativité dans ses méthodes.