Les 8 commandements de la R&D chez Equisense 🐴 🤓

Ca fait maintenant 2 ans que je m’occupe de la démarche scientifique chez Equisense. Et comme toute start-up qui se respecte, on a eu quelques loupés 😅… Il faut dire que contrairement à de la R&D “classique”, le contexte startup induit une notion de temps très court ⏲ et avec des moyens limités 💵 qui compliquent fortement la démarche.

Quand on te dit que tu as 3 mois pour sortir une nouvelle feature qui aurait pris 3 ans en recherche “classique” …

Le côté positif de ça c’est que chaque erreur ou “échec” est une source d’apprentissage fabuleuse. Comme on dit chez nous : Send Shit to Space !
💩 → 🚀. Voilà donc un petit florilège de nos apprentissages en R&D et les outils qu’on a mis en place pour ne plus recommencer deux fois les mêmes erreurs.

Hardware + cheval = double complexité

Notre particularité c’est que nous sommes une start-up hardware : nous développons des objets connectés pour les cavaliers et leurs chevaux. Nous avons donc des prototypes à base d’Arduino, avec des capteurs, des fils, des émetteurs, des récepteurs, avec du Bluetooth, du Wifi, des ordinateurs … On doit aller les tester sur le terrain 🐴 pour voir si ça fonctionne (donc prendre notre voiture, ce qui signifie avoir bien tout prévu à l’avance et ne rien oublier), dans le sable ou dans la paille, avec l’odeur de crottin qui nous berce 👃💩, avec un cheval qui bouge dans tous les sens, avec tous ses poils qui nous compliquent franchement la tâche, le tout parfois dans des nuages de poussière qui nous projettent bien loin des salles blanches… On doit comparer les résultats qu’on obtient avec d’autres outils qui font foi (des gold standards) mais qui coutent souvent une fortune, donc on doit trouver des solutions alternatives, on doit faire des algorithmes de traitement du signal, les embarquer dans nos devices, vérifier qu’ils fonctionnent bien, que l’app dédiée affiche bien les bons résultats, etc. Tout ça est donc beaucoup plus lourd qu’une “simple” app à faire tourner sur iOS et Android… Ceci nécessite donc une organisation au poil 👌 dont je vais essayer de vous livrer quelques secrets ici.

©Equisense

#1 Un bon process tu auras 📝

Une bonne structuration des équipes (qui fait quoi) et une bonne planification (quand et comment) sont primordiales pour le bon développement de produits complexes. De notre côté, voilà comment on a organisé les échanges entre les différents “pôles” :

Dans les faits, l’organisation est très fluide, la hiérarchie très horizontale et les pôles sont constitués d’au maximum 3 personnes, mais le fait d’avoir une bonne structuration et un bon process qui soit à la fois complètement viable, facile, utile et adapté, nous permet de bien gérer les échanges, éviter un tas de problèmes, mieux identifier d’où viennent les erreurs et donc mieux les corriger, et anticiper les besoins de chacun.

#2 En équipe tu travailleras 👨‍👩‍👧‍👦

On s’est rendu compte qu’on avait facilement tendance à être chacun de notre côté malgré l’open-space que l’on partage (à 20…). Or, le partage d’informations et la remise en question permanente par ses pairs est complètement indispensable pour que les bonnes décisions soient prises au bon moment et avec toutes les cartes en main.
On a donc décidé de mettre en place des petites réunions par équipe, type scrum/stand-up, toutes les semaines ou toutes les deux semaines. On a donc 1 scrum technique, 1 scrum marketing et 1 scrum R&D. Dans ce dernier, on réunit un mardi sur deux les product owners, les deux ingénieurs recherche, la designer industriel et l’ingénieur firmware dans une écurie, face à un cheval 🐴 pour pouvoir montrer les problématiques que chacun d’entre nous rencontre, tant dans les contraintes environnementales, matérielles ou design. En effet, la réalité est parfois bien loin du bureau, et pour ne pas être complètement à côté de la plaque, c’est un petit effort qui finalement se trouve être bien utile. Et puis ça nous fait prendre le grand air, ça fait du bien 😉

#3 Des specs précises et une roadmap tu auras 🗺

Il nous est arrivé, pour certains produits ou fonctionnalités, de ne pas avoir de spécifications précises, parce qu’on se l’était dit à l’oral ou parce que ça nous semblait évident, ou parce qu’on ne voulait pas avoir de process trop lourds… Au final on y a perdu beaucoup plus de temps.
On a donc mis en place d’une part une roadmap globale (très “big picture”), avec des jalons intermédiaires, qui regroupe tous les produits que l’on développe. A chacun ensuite de se responsabiliser et de s’organiser à sa manière et avec ses outils pour respecter ces jalons, pour ne pas aller dans le micro-management, qui n’est pas vraiment notre tasse de thé.
D’autre part, chaque produit a désormais ses specs qui rassemblent les contraintes techniques et les usages de manière bien détaillée dans un document partagé.
Dans les deux cas, les documents sont co-construits pour tenir compte des contraintes de chacun et pour prendre les bonnes décisions en tenant compte des restrictions que chacun émet.

#4 L’apprentissage des connaissances théoriques tu pousseras 📚

En voulant avoir “l’esprit de hacker”, on a eu tendance à vouloir aller trop vite sur les pré-tests et à écourter l’étape état de l’art. On a donc été confrontés plusieurs fois à des résultats que l’on ne comprenait pas ou que l’on ne savait pas expliquer tout simplement parce qu’on ne s’était pas assez attardés sur les bases théoriques, physiques et chimiques de ce qu’on voulait mesurer. Or, on ne peut bien concevoir des tests que si on sait exactement ce qu’il faut aller chercher et comment.
On passe désormais plus de temps à lire des articles scientifiques, des livres spécialisés, à regarder des vidéos, des moocs, ou à rencontrer des professionnels pour être sûrs de maîtriser tous les phénomènes sous-jacents.

#5 Du matériel de bonne qualité tu fabriqueras / tu utiliseras 🔨

De la même manière, sous couvert de l’“esprit hacker” on a parfois voulu trouver des solutions très rapides mais pas du tout adaptées aux conditions “de l’extrême” que nous imposent les tests sur les chevaux. Or il est impossible de faire un test répétable ou bien d’isoler les différentes choses à étudier avec du matériel non robuste, mal fixé, qui tombe, qui fonctionne une fois sur deux ou que l’on n’a pas retesté après avoir fait des changements hardware.

Pour contrer ça, d’une part, on a mis en place des protocoles de tests “sur table”, que l’on recommence régulièrement avant de partir sur le terrain, pour être sûrs que tout fonctionne et que les résultats soient cohérents dans un contexte parfaitement maîtrisé. C’est comme ça que vous pourrez croiser Alice, notre ingénieur R&D, avec des électrodes ECG collées partout sur le corps et autant de câbles reliés à son ordinateur, en train de sauter pieds joints devant son bureau, ou encore Kamel en train de faire des cercles “au pas et au trot” dans l’atrium qui jouxte notre open-space.
D’autre part, on a appris à dégainer les outils de notre mini fablab, comme la machine à coudre par exemple pour nous fabriquer des pochettes / tapis / sacs, pour garantir une stabilité parfaite de notre matériel lors des tests.

La machine à coudre, notre allié numéro 1 pour rajouter cette magnifique pochette faite main, entièrement tapissée de scratch à l’intérieur, garantissant une stabilité parfaite de notre matériel. ©Equisense

Il vaut mieux passer 15 ou 30 min à fabriquer du matériel robuste et adapté plutôt que de casser nos prototypes, de biaiser nos tests à cause des mouvements et d’être incapable à la sortie d’identifier d’où vient le problème.

#6 Des tests structurés tu feras 📐 📏

Là encore, il ne faut pas confondre vitesse et précipitation. En voulant à tout prix avancer sur le sujet, on s’est retrouvés parfois à faire des tests sans avoir d’objectif vraiment précis.

Voilà comment on procède désormais :
1) Après avoir épluché toutes les publis et tous les moocs disponibles sur le sujet en question, on déconstruit le problème pour en comprendre toutes les composantes et identifier les zones d’ombres, les inconnues ;
2) On émet des hypothèses ;
3) On fait un plan de pré-tests pour valider ou invalider les hypothèses ;
4) On passe à la phase de pré-tests.

Concernant la phase de pré-tests, pour éviter les loupés on a mis en place certains outils qui se révèlent plutôt utiles :

• Avant de partir sur le terrain on remplit un questionnaire Google Form sur lequel on explique le test qu’on va faire, pourquoi, comment, ce qu’on cherche à obtenir comme réponse, qui y va et quand. Et surtout, ce Google Form contient également la checklist du matériel à emporter, ce qui nous évite bien des déconvenues. Ces formulaires sont automatiquement envoyés sur Slack grâce à Slackbot qui nous renvoie le bon lien et grâce à Zapier qui nous envoie un message quand quelqu’un a rempli le formulaire avec le lien vers les réponses. Grâce à ça, tout le monde peut y jeter un oeil, ça nous aide à garder du recul sur ce qu’on fait et ça nous oblige à structurer notre démarche.

L’automatisation nous permet de garder une structure et limite les risques. ©Equisense

• Au retour du test, même procédure, on remplit le Google form de compte rendu qui nous demande ce qu’on a fait, ce qu’on a eu comme résultat, pourquoi on a eu ces résultats (ce qui nous oblige à systématiquement challenger notre méthode et à pousser plus loin la réflexion), quelle est la prochaine étape, etc. De la même manière, les résultats sont automatiquement renvoyés sur Slack pour que tout le monde puisse suivre et qu’on avance tous avec le même niveau d’information.

Les comptes rendus sont simples mais structurés et nous permettent une meilleure transmission de l’info ©Equisense

Google Form est un outil parmi tant d’autres, mais il nous permet de capitaliser tous les résultats en un seul document bien structuré. Il est donc très aisé pour quiconque de revenir voir quels tests ont été effectués quand avec quel matériel sur quel type de cheval, les résultats qui ont été obtenus, les conclusions qu’on en a tirées et donc d’identifier les zones d’ombre qu’il reste à élucider, et de prendre les bonnes décisions pour la suite.

#7 Beaucoup de données tu acquerras 📈

Mieux vaut un algorithme moyen avec beaucoup de données qu’un algorithme parfait avec très peu de données.

Ca on l’a expérimenté aussi au tout début de l’aventure. On avait commencé à développer certains algorithmes de détection d’événements sur seulement quelques datasets acquis sur des chevaux relativement similaires : ça marchait hyper bien ! Et puis on a lancé la version beta sur une petite quarantaine de personnes … et ça marchait beaucoup moins bien 😞. Même si le rôle de beta-testeurs consiste aussi à challenger nos résultats, on préfère mieux tester en interne sur un maximum de chevaux différents, de taille et de poids différents, avec des locomotions différentes, dans des conditions différentes, pour essayer de ratisser le plus large possible avant la mise en prod de nouvelles features. Notre objectif c’est en fait de gommer les effets de bords et d’avoir suffisamment de données pour couvrir tous les cas ou presque, pour faire en sorte de créer un effet de lissage sur des cas qu’on n’aurait pas forcément imaginés à la base.

#8 Des golden samples tu créeras 💻

En fait on s’est trouvés un certain nombre de fois face à des différences de résultats entre les algorithmes Matlab que l’on développait en premier lieu et les algorithmes une fois passés en C et embarqués dans nos capteurs. C’est donc pour automatiser ce processus de testing, mieux maîtriser le taux d’erreurs et fiabiliser les versions que l’on met en prod, qu’on a mis en place le système de golden samples.

Le principe est simple. Prenons l’exemple suivant : je veux faire un golden sample pour valider l’algorithme de fréquence cardiaque. Je vais alors poser notre système d’acquisition sur le cheval + un système qui fait référence (en l’occurrence le Televet 100 de la marque Engel Engineering Systems GMBH) et je fais les deux acquisitions en parallèle. Je vais ensuite récupérer les données brutes de mon acquisition (l’ECG) et créer un fichier dans lequel je vais indiquer la fréquence cardiaque calculée toutes les secondes par le Televet. On va ensuite développer un algorithme de calcul de la fréquence cardiaque à partir de l’ECG, que l’on va mettre dans la machine virtuelle. On fait ensuite passer l’ECG que j’ai acquis avec mon système dans la machine virtuelle et on compare les résultats de l’algorithme avec les résultats du Televet pour voir si l’algorithme est correct.

On a donc un jeu de datasets très hétérogènes (toutes disciplines, tous types de chevaux, etc.), pour lesquels chaque indicateur est vérifié soit manuellement (pour les événements ponctuels comme les sauts par exemple), soit grâce à des outils de type gold standard (comme le Televet). Les données brutes de ces datasets parfaitement labellisés sont envoyées dans une machine virtuelle (qui reproduit le comportement de notre device) qui nous permet de comparer les résultats des algorithmes embarqués aux résultats des golden samples. Si les résultats sont identiques (ou que le taux d’erreur est dans la fourchette d’acceptabilité), on considère que l’algorithme embarqué est validé et qu’il peut partir en version beta. Si les résultats diffèrent trop alors on cherche point par point d’où peut venir le problème et on recommence la boucle une fois le problème réglé.

Take home message 🏠

• Le fait d’être une startup et toutes les contraintes (⏲ 💵 etc.) qui s’imposent n’empêche pas d’être bien structuré. Au contraire !!
• La hiérarchie horizontale est compatible avec une structure et les process n’empêchent pas la coolitude et l’agilité.
• L’apprentissage et l’état de l’art n’est jamais une perte de temps 🎓 (d’ailleurs à ce sujet je vous conseille vivement l’article de Benoit, notre CEO ❤️ → “Hackez votre courbe d’apprentissage”).
• L’esprit de hacker que l’on se doit d’avoir n’empêche pas de faire du matériel robuste 💪.
• L’automatisation 🤖 vous permet d’éviter bien des problèmes.
• Sachez capitaliser et apprendre de vos erreurs. Et il n’est jamais trop tard pour faire une rétrospective … même au bout de 2 ans 😉

Et puisqu’on a parlé d’une certaine forme d’échec tout du long, je ne peux m’empêcher de vous conseiller plus que vivement la lecture du livre de Charles Pépin “Les vertus de l’échec”. Je vous souhaite qu’il vous permette, comme je viens de le faire, de presque prendre du plaisir à vous remémorer vos erreurs passées, en espérant gagner en sagesse et tendre vers “l’authentique réussite” ❤️ 😉.