S03E13 · Les cycles de développement dans l'IoT

0:05 Une des particularités du réseau CFOX, c'est d'avoir la rétrocompatibilité à vie concernant les devices. Donc il n'y a pas non plus d'obsolescence programmée chez nous. Le produit, une fois chez le client, on le maintient. Jusqu'alors, on a maintenu tous nos produits. Et on essaie d'avoir cette espèce de petit roulement où de temps en temps, on fiche un peu la paix, j'ai envie de dire, aux gens, de manière à ce qu'ils soient créatifs. Beaucoup de petits pas qui mènent à une grande histoire. Bonjour à tous, je suis Jérémie Clévy, DG de Tech.Rocks. Bienvenue dans ce nouvel épisode de la saison 3 de nos podcasts. Et aujourd'hui, nous allons nous plonger dans l'IoT, l'Internet des objets, avec nos deux invités que j'accueille avec grand plaisir, Nathalie Lamy et Christophe Fourtel. Bonjour tous les deux. Bonjour Jérémie, bonjour Christophe. Bonjour. Alors, qui êtes-vous? On va commencer par les présentations et c'est Nathalie qui commence.

1:07 Donc Nathalie Lamy, je suis VP Engineering chez Netatmo qui fait partie du groupe Legrand. Notre terrain de jeu c'est la maison connectée et je pilote une équipe de 140 personnes dans les métiers hardware et logiciel. Et c'est absolument passionnant. Et Christophe? Christophe Fourté, je suis un des cofondateurs de Sigfox. Actuellement, je suis CSO de Sigfox, chief stratégie, science officer, comme vous voulez, peu importe. Évidemment, plutôt le cofondateur technique, on va dire, de la société. Et voilà, Sigfox, c'était environ 300 personnes, dans l'IoT bien entendu. Merci beaucoup, bienvenue. Je précise évidemment que les points de vue que vous allez développer sont les vôtres, pas nécessairement ceux de vos sociétés respectives. Alors évidemment, le thème que je voulais aborder avec vous en premier, c'était l'IoT, parce que vous êtes en plein dedans. Nathalie, toi tu fabriques des objets intelligents, et qui ont une durée de vie longue chez le client.

2:10 Et Christophe, tu as créé, comme tu nous le disais, un des réseaux qui permettent aux objets de se connecter entre eux ou de se connecter avec des serveurs distants. Nous, dans les gens qu'on accueille dans le podcast, on a beaucoup, beaucoup de gens qui font plutôt du web et qui sont relativement loin de vos technologies. Est-ce que déjà, on pourrait commencer par essayer de qualifier, ces technos, les vôtres, est-ce que vous pouvez nous dire d'un point de vue du développement, ce qui est spécifique à l'IoT par rapport aux autres technos? Donc je commence. Donc effectivement, nous développons des objets, donc ça veut dire du hardware, de l'électronique, de la méca, il y a toute une partie aussi industrialisation pour... Piloter la production dans les usines nos sous-traitants. Donc c'est vrai que ça implique des cycles de développement sûrement très différents du logiciel pur. Et ensuite, c'est par rapport à des boîtes qui feraient du hardware quand même, le fait que ce soit des objets connectés, peut-être que la spécificité c'est que

3:11 déjà on a cette connexion, on peut remonter des données, mais on peut aussi mettre à jour les produits, en tout cas chez Netatmo, à distance. Et donc ça en fait des produits évolutifs qui ne sont pas figés à un instant T et qui vont... Avoir des nouvelles fonctionnalités mises à jour plus tard dans la vie du produit. Et de ton côté, Christophe, quelle spécificité tu vois? Nous, en fait, la première spécificité, c'est que c'est un... un aspect un peu système, c'est-à-dire qu'on a créé un système de toutes pièces. Donc, il y a une notion architecture, en fait, architecture et système, sur laquelle on a travaillé, et il faut qu'on continue à travailler, puisqu'on est garant de la qualité de tout ça. Tout ça reste en ordre et éventuellement évolue. Donc, de fait, pour ce qui concerne en tout cas l'infrastructure, on a une activité hardware, logiciel embarqué, logiciel cloud. Il y a toutes ces composantes métiers.

4:14 qu'il faut marier à l'intérieur de l'entreprise et faire fonctionner en ordre, on va dire. C'est vraiment la spécificité de Sigfox, c'est ça. Et du coup, est-ce que vous avez des méthodes de production qui mériteraient d'être connues par les autres tech leaders qui nous écoutent et qui ne sont pas forcément dans votre industrie? Oui, alors il y en a une qui nous concerne et qui est assez paradoxale par rapport à notre offre d'ailleurs, puisque une des particularités du réseau Sigfox, c'est d'avoir la rétrocompatibilité à vie concernant les devices, les terminaux, les petits machins qui sont sous le réseau, où nous on est garant du fait qu'on va pouvoir servir ce device, même s'il a été introduit il y a 20 ans et qu'il y a de nouvelles features qui ont été introduites. Du coup, dans notre réseau, il y a une politique de rétrofit de l'infrastructure, un mécanisme de rétrofit qui est très rigoureux. Donc ça, c'est quelque chose d'extrêmement précis, très rigoureux qu'on a en place et qui peut-être n'est pas, en tout cas à ce niveau de rigueur, partout.

5:20 Vous avez à peu près la même chose chez Netatmo, Nathalie? Non, je pense que c'est un peu différent. La spécificité de production chez Netatmo, c'est que les produits qu'on fabrique chez les sous-traitants, la partie hardware, doit être hyper bien qualifié, donc ça je pense que c'est le cas aussi chez Christophe, hyper bien qualifié parce que le produit, une fois qu'il est chez le client, lui, on ne peut plus y toucher la partie vraiment physique, donc il faut vraiment tester à 100% tous les produits sur la ligne de production, et ça, c'est sûr que c'est... Tous les gens qui font du hardware le font, évidemment. Donc, il n'y a pas non plus d'obsolescence programmée chez nous. Le produit, une fois chez le client, on le maintient. Jusqu'alors, on a maintenu tous nos produits en mettant à jour des fonctions, en corrigeant évidemment les anomalies, en mettant à jour la partie sécurité. En revanche, je ne sais pas exactement ce que tu voulais dire Christophe par rétrofit, mais on ne remplace pas la partie physique des produits chez les clients, sauf évidemment en cas de dysfonctionnement.

6:30 auquel cas, il renvoie son produit à notre support client et on lui renvoie un produit. Le produit réparé ou un produit neuf, si on ne peut pas le réparer. Mais il n'y a pas de... Pour le moment, on n'a pas eu besoin... Nous, on fait du B2C, donc on vend des produits à des utilisateurs finaux. Donc, une fois le produit vendu, il est vendu une fois, il n'y a pas d'abonnement, donc il n'y a pas d'obligation quelque part de rétrofit. Peut-être que tu peux préciser ce que tu voulais dire par rétrofit? Tout à fait. Je n'ai certainement pas été assez précis. En rétrofit, le mot n'était pas tout à fait bon, puisque je parlais essentiellement de rétrofit logiciel. Reprogrammation des nœuds du réseau, etc., des dispositions d'infrastructures, même s'il est vrai qu'on peut avoir à faire du rétrofit physique dans un réseau, plus tard on le fait, mieux on se porte, bien entendu.

7:32 On a aussi, bien entendu, des méthodes pour aller remettre des nouveaux matériels sur des sites, mais la spécificité la plus particulière qu'on a chez nous, c'est ce rétrofit logiciel des stations, où là, en fait, étant garant de la qualité du système, Il ne faut pas qu'on se trompe. Et en fait, il y a un effet de déploiement qu'on peut, je suppose, aussi avoir chez Netatmo, mais... qui est plus focalisé sur un produit final, là où nous, il y a éventuellement une catastrophe fonctionnelle globale possible, Et donc, forcément, ça a une incidence sur la manière dont on le fait, parce qu'il ne faut surtout pas qu'on se trompe et qu'on met par terre le réseau. C'est une catastrophe. Oui, même si nos clients sont des utilisateurs finaux, des particuliers, on a aussi le fait que si côté logiciel embarqué, on a découvert une anomalie dans le logiciel, on doit déployer le nouveau firmware corrigé sur tout le parc.

8:42 c'est à la fois un avantage, enfin je pense que c'est ce que tu veux dire aussi Christophe, à la fois c'est une force, c'est-à-dire qu'on peut corriger des choses qu'on n'avait pas vues en phase de développement, et c'est en même temps un gros risque, puisqu'on peut tout casser, et donc les firmwares qu'on met à jour à distance, il faut vraiment bien les tester avant le déploiement. Voilà, c'est vrai que côté back-end, je veux dire, et là tout le monde, tous les gens qui nous écoutent connaissent ça, côté back-end, évidemment, il ne faut pas faire n'importe quoi non plus. Je veux dire, ce n'est pas parce qu'on peut le corriger en live qu'il faut casser le service pendant plusieurs minutes, plusieurs heures pour autant. Donc, il faut évidemment faire appliquer la même rigueur pour les tests côté back-end, mais c'est vrai que l'impact n'est pas la même. Et à quelques... Je trouve que la culture hardware et logiciel embarqué, où on a toujours à l'esprit qu'on pourrait briquer les produits des clients et du coup être obligé de faire un échange physique de produits parce qu'on n'arrive pas à les débloquer à distance, d'avoir ça en tête, ça permet d'être peut-être plus rigoureux sur les autres parties du logiciel.

9:51 J'ai l'impression qu'il y a quand même une culture du zéro bug obligatoire, sinon c'est la cata dans le métier. Oui, bien sûr. Oui, c'est évident. Je pense que Nathalie pourra confirmer. Dans ces métiers, même si vous l'avez compris, ce qu'on fait chez Sigfox est différent de ce qui se fait chez Netatmo. Typiquement, Netatmo, c'est des produits relativement sophistiqués en B2C. Là où nous, c'est une infrastructure, on va dire en B2B pour simplifier, Il y a évidemment des spécificités, des différences, mais c'est certain que dès qu'on a des produits qui doivent donner un service régulier et sans bug, il faut être extrêmement rigoureux, bien entendu. Mais j'ai presque envie de dire, il y a plein d'industries qui sont comme ça, on n'est pas les seuls. Oui, bien sûr. Et en parlant de rien oublier, il y avait une question qui me trottait dans la tête en préparant ce podcast, c'est quoi vos grandes angoisses dans l'IoT?

10:57 C'est le piratage massif de tes devices chez des millions de personnes, Nathalie, ou c'est la micro-panne de rien du tout qui va clouer au sol tous les avions et les trains dans le monde entier parce qu'ils dépendent du réseau CFOX? C'est quoi vos angoisses? On a déjà parlé tout à l'heure de la panne généralisée qui aurait un gros impact, puisque s'il faut rapatrier tout le matériel, soit parce que c'est une panne électronique ou mécanique, soit du logiciel embarqué. Mais en ce moment, c'est vraiment la seule. sécurité qui me qui me m'empêche de dormir si je puis dire c'est à dire que bon on a toujours été très à cheval là dessus il ya quelques années je sais plus si c'était il ya deux ou trois ans on a vraiment mis un accent encore plus là dessus en recrutant une équipe dédiée sur la sécurité pour être vraiment spécialisé dans les... Enfin, voilà, chercher des outils qui permettent de détecter des vulnérabilités, aider les développeurs et les développeuses à durcir leurs codes, à détecter les vulnérabilités en amont, assurer une veille permanente.

12:05 Et ça nous a permis de vraiment monter en compétence. C'est-à-dire qu'avant, on croyait qu'on était bon, mais on s'est rendu compte qu'on pouvait en être encore meilleur là-dessus. Et c'est vraiment... Oui, on sait que les objets connectés, par définition, sont plus susceptibles d'être piratés que des objets non connectés, c'est certain. Nous, c'est évidemment la sécurité aussi, bien sûr. Je pense que c'est un sujet qui est partagé par tous les acteurs de l'IoT, de toute façon. Nous, avec une particularité qui est que, on a des objets, en fait nous on est l'IoT des objets très simples, voire même simplissimes, qui fait que ça nous aide à ce niveau, en tout cas la partie R-interface, entre guillemets, la partie sécurité interface est assez simple à gérer de manière extrêmement robuste, parce que c'est simple. Il y a toujours l'attaque physique sur le rôle. Le produit, bien entendu, mais ça, j'ai envie de dire, ça regarde le client. À nous de lui donner les bons conseils, bien entendu.

13:07 Mais après, nous, on a la partie réseau, la partie réseau qui doit être évidemment protégée. Il ne faut pas pouvoir s'introduire dessus, etc. Je pense que la bonne pratique, je suis certain que Netatmo le fait, pas tous les gens sérieux du domaine le font, c'est d'avoir des audits, d'essayer de se confronter à la menace. Et régulièrement, en fait, il n'y a pas de répit. Régulièrement, il faut regarder et éventuellement corriger. L'audit, il est fait par des tiers ou il est fait par vos équipes, ou les deux d'ailleurs? Genre, vous avez des hackers spécialisés dans votre équipe qui essayent de breaker vos devices ou vos réseaux? Il y a les deux. On a fait, nous, des essais. Alors, il y a la sécurité, mais il y a aussi des mécanismes, il y a aussi des potentiels mécanismes auxquels on n'a pas pensé dans la chaîne complète. C'est-à-dire, par exemple, tel type de requête qui arrive massivement sur le cloud et qui fait que le cloud n'a pas été prévu pour gérer exactement ça.

14:10 Donc ça, on le teste souvent en interne, évidemment. En fait, on a des systèmes de tests. Et donc, on a des gens qui sont spécialisés là-dedans en interne. Mais de toute façon, le tiers est obligatoire. Il faut obligatoirement avoir des tiers, c'est important. Tu fais pareil chez Netatmo, Nathalie? Oui, tout à fait. L'équipe dédiée fait effectivement des audits. audite interne et elle peut déjà faire un premier filtre, on va dire. Et ensuite, on fait des audits externes pour tous nos produits. Donc, qui permet, enfin, voilà, qui sont encore plus spécialisés et qui ont l'habitude. Qui voient d'autres produits que les nôtres. Donc, ça permet d'avoir aussi un autre regard. Et donc, ça permet de détecter des vulnérabilités avant que le produit soit mis sur le marché. Et alors, tous les deux, Je comprends que la cybersécurité, c'est un truc très important. Mais je pense que l'innovation aussi, c'est quelque chose d'assez important. Vous êtes sur des secteurs relativement concurrentiels.

15:12 Comment est-ce que vous organisez votre R&D? C'est un marché concurrentiel, effectivement, et de mon point de vue, c'est une très bonne chose. S'il y a de la concurrence, ça veut dire qu'il y a un marché. Et c'est le plus important quand même quand on lance une entreprise. Donc face à la concurrence, il n'y a pas de miracle. Je pense que c'est le nerf de la guerre pour tout le monde. C'est qu'il faut essayer d'être là. Au moment où le besoin existe, donc pas trop tôt, mais évidemment pas trop tard, donc il faut être là à peu près en même temps que les concurrents, et si possible un petit peu avant. Donc voilà, on fait comme tout le monde, on essaye de sortir les produits le plus vite possible, mais ce n'est pas toujours si évident que ça, puisque quand on fait du hardware, les cycles de développement sont un peu... peut-être plus long que dans du logiciel. Vous êtes sur des rythmes qui, ça dure combien de temps, entre la feuille blanche et le produit disponible chez le user? Suivant la complexité des produits, ça peut, enfin, disons qu'en général, on dit 18 mois, mais ça peut être plus long quand même, quand ce sont des produits plus complexes.

16:17 Quand côté mécanique, il y a des gros challenges, ça peut être plus long, oui. Et côté Sigfox? Déjà, je rebondis sur ce que disait Nathalie, les grands classiques. 18 mois, effectivement. Alors, il y a un truc que j'ai appris, c'est qu'on sait bien calibrer l'industrie hardware. Quand il y a un produit physique à fabriquer, finalement, il y a des références qui sont sur deux siècles, j'ai envie de dire. Moi, mon expérience, c'est qu'un produit moderne, il est souvent ralenti par le logiciel. C'est souvent le logiciel à la fin qui a des petits problèmes et on n'est peut-être des fois pas allé assez loin dans le test, etc. Et toujours ce réflexe, même si on s'en défend, On s'en défend, bien entendu, avec toutes les méthodes connues, etc. Mais inconsciemment, c'est toujours ce principe du… Or, c'est du logiciel, donc on pourra corriger.

17:20 Et des fois, ça joue des tours. Mais bon, en tout cas, les durées qu'évoquait Nathalie sont des grands classiques. Nous, on a une partie innovation sur la partie système qu'il faut maintenir. C'est-à-dire qu'on est obligé, on doit réfléchir au coup d'après. En ce moment, on est dans une grande réflexion, que je ne vais pas décrire ici, bien sûr. On est dans une grande réflexion sur un nouveau segment de marché qu'on veut… créer et investir. Et tout ça, ça demande des réflexions. Alors, réflexion système, là, en l'occurrence, puisqu'il y a une chaîne complète, c'est là où nous, on passe quand même pas mal de temps. Il faut maintenir ce momentum. C'est obligatoire de maintenir ce momentum de R&D dans une boîte technique. De toute façon, on ne peut pas y couper. On a un peu la même chose sur la partie algorithme, donc traitement du signal et traitement de l'image machine learning, où il y a des personnes qui font de la recherche sur des algorithmes qui, on espère, iront dans nos produits, mais pas toujours.

18:24 Suivant ce qu'on arrive à faire au niveau performance et efficacité de l'algorithme. Donc ces personnes-là, évidemment, ne sont pas sur ce cycle. Le cycle de 18 mois ou plus dont je parlais, c'est plus sur un produit dont on sait ce qu'on veut mettre dedans, quelque part. Et du coup, est-ce que vous pouvez me donner une proportion, plus ou moins, dans vos équipes, qui est consacrée à la R&D? Oui, l'ordre d'idée, c'est qu'on a à peu près 20% des gens qui font de la R&D. 20% des gens qui font de la R&D. Et on essaye d'avoir des espèces de roulements, j'ai envie de dire. C'est-à-dire que quelqu'un qui… En fait, je pense que c'est important, Nathalie nous dira si elle voit la même chose chez elle, mais c'est important de temps en temps de laisser une ou deux personnes en roue libre parce qu'ils ont bien donné sur un projet. Et si c'est les bonnes personnes, ils vont peut-être trouver des idées. Et on va voir si ces idées sont applicables ou pas.

19:25 Et éventuellement, on les réinjectera dans des projets après. Mais on essaie d'avoir cette espèce de... de petits roulements où de temps en temps, on fiche un peu la paix, si j'ai envie de dire, aux gens, de manière à ce qu'ils soient créatifs. Ce n'est pas facile, mais essayer de maintenir cette espèce de créativité dans l'entreprise, nous, ça nous semble important. Alors, nous, c'est un peu différent parce que... Vraiment, le R de R&D, c'est-à-dire la recherche pure, c'est très peu de personnes. Sur les algorithmes dont je parlais, c'est moins. De 10 personnes sur les 140 que je disais. Et ensuite, sur ce qui est plutôt dans la partie développement, et donc la plupart des gens, on va dire qu'ils consacrent 60% de leur temps à faire des produits, 20% à faire de ce qu'on appelle de la productivité, et donc peut-être des sujets avec moins de pression pour sortir. Un produit, mais c'est finalement maintenir, mettre à jour la plateforme technique qui soutient les produits.

20:36 Mais on fait 20% de maintenance. Donc, sur cette partie productivité, nous, en fait, on ne fait que... Ce qui nous semble vraiment utile. Donc, il y a très peu de... d'exploration technique, ce qui n'a pas vocation à rentrer un jour dans un produit quand même. Oui, je pense que ça revient un petit peu au même finalement. Parce qu'effectivement, nous, dans les 20% que j'ai décrits, il n'y a pas 20% de gens qui font du R, bien sûr, il y a beaucoup de développement. Simplement, on essaie, alors je suis d'accord qu'il y a des gens qui sont souvent plus consacrés au R qu'au D, bon mais ça, ça dépend aussi des sensibilités des personnes, mais on essaie d'avoir ces espèces de roulements quand même. Il y a des gens qui peuvent avoir passé un certain temps dans du développement et qui à un moment donné, On va les laisser pendant deux mois sur un sujet un petit peu plus R. En revanche, là où je suis d'accord, c'est qu'alterner les projets où il y a une deadline, parce qu'il faut absolument sortir le produit, justement, comme on disait peut-être avant la concurrence, c'est quand on peut,

21:48 et alterner avec des sujets plus de fond pour... Pour réduire la dette technique, pour utiliser un nouvel outil pour détecter, je ne sais pas, des vulnérabilités ou automatiser des tests, des sujets plus de plateforme, on va dire. Ça permet d'alterner un peu les rythmes. Et tiens, c'est intéressant ce que vous dites là tous les deux, cette espèce de roulement un peu, à un moment on est sur un projet pendant quelques mois, et ensuite on s'aère en essayant d'être dans de la prospective, et puis après on rechange, etc. Et ça va, mais une autre question, c'est de quels profils sont constituées vos équipes? Alors, ils n'ont pas forcément un diplôme d'ingénieur. Mais disons qu'en général, c'est souvent Bac plus 5, mais pas que. Il y a des développeurs qui sont soit autodidactes, soit qui ont un Bac plus 3, etc. Mais la majorité, oui, ce sont des ingénieurs.

22:52 Et dans l'équipe qui fait du traitement... Machine learning et du traitement du signal, il y a aussi des documents. Docteur ? Des PhD. Oui, c'est un classique, je dirais. C'est un classique. C'est à peu près la même chose sur Sigfox. C'est majoritairement des ingénieurs. On a quelques personnes qui peuvent, effectivement, je pense à quelques personnes qui sont autodidactes ou qui ont fait plutôt des études de cours, mais qui sont très... Très passionné et évidemment quelques PhD sur certains sujets bien sûr. Et comment on fait pour faire travailler des gens vraiment, je dirais, ingénieurs hard sur du hardware et d'autres qui font du soft et des algos? Comment ça bosse ensemble? Parce qu'ils sont radicalement différents, on ne fait pas du tout et c'est très simple. Comment tu as organisé ça Nathalie? Puis je poserai la même question à Christophe. Alors chez nous, ça se passe très très bien. Les électroniciens, les mécaniciens sont quelque part agiles aussi à leur manière.

23:56 Ils ne font pas autant d'itérations évidemment que sur le logiciel pour aboutir à la version finale, mais ils ont quand même cette habitude de, il y a la phase de prototype, la phase d'engineering sample, la phase de pré-prod, etc. Et à chaque fois, c'est des itérations évidemment plus longues et plus coûteuses, parce que quand on fait des engineering samples, on en fabrique plusieurs pour être sûr que c'est répétable. Et donc, à chaque fois, il y a une bonne synchronisation avec l'équipe logicielle embarquée pour que l'équipe logicielle embarquée puisse aider. l'équipe hardware a validé sa version de carte électronique. Puis donc il y a des points de rencontre quelque part où il faut que les deux équipes se rencontrent. Et c'est vrai que l'équipe logicielle embarquée, elle est un peu entre les deux parce qu'elle doit d'un côté aider l'équipe hardware à valider la plateforme physique et de l'autre, elle travaille avec les équipes back-end et applications pour... Faire les fonctions logicielles du produit dans un cycle plutôt itératif.

25:00 Alors déjà, moi, je tiens à préciser qu'en réalité, beaucoup de gens qui font du hardware, qui ont plutôt la fibre hardware, savent aussi coder. Alors, ils sont... Ce ne sont pas des spécialistes du logiciel. C'est vrai que des spécialistes du logiciel embarqué, parce qu'ils y ont passé plus de temps, ils sont plus adroits, ils sont plus rapides, etc. Ça, c'est une chose. En tout cas, ce n'est plus cette époque où il y avait des gens qui ne faisaient que du hardware. Dès qu'il y avait une ligne de code à faire, il fallait qu'ils fassent appel à quelqu'un. Moi, ce que j'essaie d'appliquer, ce que j'ai essayé d'insuffler dans Sigfox, c'est ce que j'ai appris de deux grands maîtres, on va dire. Pierre Faure, l'ancien patron de Sagem, et puis Guy Rouane, qui était patron des entités télécoms. C'est cette notion de plateau, en fait. C'est-à-dire que le plus possible, ce n'est pas toujours facile, pour X raisons, mais d'essayer, dès qu'il y a un projet qui est bien identifié, on sait que ce projet est important de le faire,

26:02 de dire, on prend une ressource hardware, on prend une ressource software bas niveau, on prend une ressource software haut niveau, on prend un mécanicien, on a peu de mécaniciens, mais on en a quand même un petit peu, quelques produits quand même sur lesquels il y a notamment les productions d'or, on va avoir quelques caractéristiques, etc. Et on essaie de mettre ces gens ensemble. Essayer de les mettre ensemble sous la responsabilité d'un chef de projet. Donc, essayer de les isoler des métiers. Alors, ce n'est pas simple. Je ne suis pas en train de dire que la partition a été écrite et il n'y a plus qu'à la jouer. Mais c'est ce qu'on essaie quand même de faire sur un certain nombre de projets. Alors j'aime bien ce que tu dis sur la partition à jouer, parce que c'est exactement l'image que j'utilise chez nous. En parlant de chef d'orchestre, mon équipe travaille avec des product managers R&D, qui sont à côté, c'est une équipe qui est à côté de moi, et ce sont de vrais chefs d'orchestre, donc à la fois ils vont traduire le besoin, quel produit on veut faire et comment ça doit se traduire en termes de fonctionnalités.

27:05 Il va aussi être le chef de projet du nouveau produit à développer. Et il va aller piocher, exactement comme ce que tu viens de décrire, il va aller piocher dans les équipes techniques les personnes dont il a besoin pour son projet. Ils vont essayer de s'isoler, je vais dire, parce que sur le papier, ils voudraient s'isoler. Mais ce n'est pas si simple quand même. Donc, pour faire son produit et essayer de se coordonner du mieux possible entre les différents métiers. Et quelque part, quand on fait la partie, ce que j'appelais productivité ou, disons, amélioration de la stack technologique du produit, Cette partie-là est plus faite directement dans les équipes techniques. Mais c'est vrai que je l'ai essayé parce que justement, du fait que la maintenance, c'est quelque chose qui peut survenir à n'importe quel moment et qu'à ce moment-là, quand il y a un problème à corriger et que c'est urgent, il faut trouver quelqu'un qui, en général, est déjà pris sur un produit, donc on le préhente un peu quelques jours, ou parfois malheureusement quelques semaines, pour corriger un problème qu'il est le meilleur

28:14 pour le traiter, parce que c'est peut-être lui qui avait fait ce développement à la base. Et donc ça, c'est vrai que c'est un peu compliqué de jongler entre... Entre les deux. Il y a toujours ces compromis, de toute façon, effectivement, au niveau organisation. Il y a toujours ces compromis à trouver entre l'organisation métier et l'organisation projet. C'est la vie, j'ai envie de dire. Oui, c'est classique. J'ai une dernière question pour conclure ce podcast et merci beaucoup à vous deux de nous avoir accompagnés. Pour prendre un peu de recul, c'est quoi vos inspirations pour progresser, pour vous projeter sur le long terme dans cette industrie? Si je peux me permettre, moi j'aime bien regarder un peu l'histoire de l'industrie. Je ne suis pas seulement un ingénieur, je suis aussi finalement un historien. J'aime bien ça, c'est une passion. Et en fait, je m'aperçois qu'il y a souvent des cycles. Il y a des cycles et on voit les apothéoses, mais on a tendance à oublier ce qui a amené à l'apothéose.

29:20 J'ai envie de dire la bulle Internet en 2000, on peut y mettre la téléphonie cellulaire avec, une espèce d'apothéose, de trucs qui explosent. On se rend compte tout d'un coup qu'un Google… Lol peut créer un empire. En réalité, on oublie que cet empire s'est assis sur un énorme cycle de création de valeurs physiques, de recherche fondamentale, d'affinage de ce qu'on appelle la télécom. Tout ça, ça a duré un siècle et même plus. Et ces sites, en fait, je pense qu'ils se reproduisent en permanence. Et moi, aujourd'hui, j'essaie de regarder… quels sont les coups d'après, indépendamment des religions, entre guillemets, hardware versus software, versus cloud, versus pas cloud, peu importe, j'ai envie de dire. Ça, c'est des choses qui existent aujourd'hui, qui sont présentes sur la scène. Et c'est quoi le coup d'après? Et moi, je m'intéresse beaucoup à la résurgence un peu du physique, je ne sais pas, avec les nanotechnologies, avec la nouvelle manière d'aborder la chimie, par exemple.

30:32 Ou l'électronique, tout simplement, parce que l'électronique aussi, on va vers des électroniques de plus en plus petites en termes d'intégration, où on voit les propriétés des semi-conducteurs qui sont en train de rencontrer les limites de la physique. Et je me dis qu'il faut toujours regarder ça parce qu'il y a des choses qui vont sortir de ça. De même que peut-être les investissements chez les Google, justement, c'est intéressant de regarder qu'ils consacrent beaucoup d'argent sur des choses qui sont très physiques. Alors, évidemment, le digital, il est là. Et j'ai presque envie de dire... L'électricité, ça a été inventé il y a 200 ans, elle est toujours là, bien entendu. Donc les choses restent. Mais il y a toujours des cycles comme ça, des choses qui réapparaissent, qui se réinventent et qui repartent, etc. Moi, c'est quelque chose que je regarde. Et toi, Nathalie? Je n'ai pas vraiment réfléchi à cette question. Je trouve ça très intéressant ce que dit Christophe, surtout que lui et moi, on a connu la bulle Internet.

31:38 Moi aussi. Donc, c'est intéressant, je trouve, effectivement, de comparer ce qui se passe sur les objets connectés avec ce qui a pu se passer dans les télécoms et le fait que c'est beaucoup de petits pas qui mènent à une grande histoire. Oui, tout à fait. Et puis une chose est sûre, c'est que la personne qui a dit l'électricité, ça ne servira à rien. Il y a 200 ans, il doit pouvoir se retourner dans sa tombe. Sans doute. C'est une techno qui nous a bien aidés tous et toutes, en effet. Eh bien, ça sera la conclusion de ce podcast. Chers éditeurs, n'hésitez pas à nous donner vos feedbacks sur le site tech.rocks ou sur les réseaux sociaux. Ils sont précieux, on en tient compte, on essaie d'en tenir compte quand c'est possible. Une note ou un commentaire sur votre plateforme d'écoute favorite, c'est la meilleure bonne action que vous pourrez faire aujourd'hui. Promis. On se retrouve la semaine prochaine pour un nouvel épisode de cette saison 3 de nos podcasts. Et merci beaucoup Nathalie Lamy, merci Christophe Fourtet de nous avoir accompagnés. Au revoir. Merci, au revoir.