Salut Christophe Horgan, ça va être, ça va, ça chie super heureux de recevoir aujourd'hui sur décidement un produit. On se connait depuis super longtemps. Je vais faire un disclaimer pour les gens qui nous écoutent, mais on a été au lycée ensemble.

On a fait plein de trucs ensemble, donc je suis super content de t'avoir aujourd'hui, toi el-Sissi, au moment de Avène, avec un objet connecté qui permet scanneurs devant, était rentré dans la boite quasi au démarrage.

C'est quasiment tout démarrage dès les premiers instants de la vie de la boite, dès les premiers instants de la vie de la boite.

Du coup, j'adore ton parcours bâtissaient. Mais du coup, j'aime bien qu'on parle un peu aux éditeurs des décimant un produit. Et comment tu passes d'un étudiant à Epitech? Ah ah! Si tu veux d'une boite à la gestion d'une équipe produit qui est un peu phénoménale et d'un produit génial qui est un produit, un produit connecté avec toute sa complexité. Déjà, est ce que pour les éditeurs qui nous écoutent, tu peux tu te présenter et présenter un peu aussi par la même occasion?

Bonjour, je m'appelle soeur Packard, j'ai 25 ans et donc je suis le directeur technique actuel d'Avène. Donc après mes études de lycée. J'avais été toujours passionné par l'informatique. J'avais toujours un peu bidouiller avec mon comme il l'a dit précédemment depuis longtemps et donc chercher un cursus où je ne voulais pas rentrer dans des cours magistraux. Toujours avoir un prof derrière rabâchées. J'ai fait Epitech en terme de cursus avec Epitech. Ça m'a ouvert pas mal de portes parce que le cursus était assez spécial.

Donc, comme j'ai dit, il y a pas tous ces cours, mais on a beaucoup de temps libre pour pouvoir faire des projets à côté et trouver du temps. Donc, j'ai travaillé à temps plein pendant toute ma scolarité et en 3ème année, j'ai rejoint un stage dont j'étais là en tant que stagiaire à Rennes. Premier développeur, Kaven a évolué pendant ma période de stage. Donc, j'ai participé. Bien sûr, c'est une startup que j'étais, comme j'ai dit.

Premier développeur, on était 4 3 et 4 5, donc vraiment pas grand monde. Il y avait le directeur technique, le président de la boite, un directeur marketing qui a fait aussi en partie design du produit. Et donc, du coup, au fil du temps, on a évolué et j'ai commencé à monter. La boite a commencé à agrandir. On a fait l'epoque, on a monté le produit. Maintenant, je me retrouve directeur technique.

Donc au tout début, quand j'ai démarré avant, c'était un prototype. Et pour décrire le prototype, c'était une bouteille en plastique avec un tuyau qui sortait. On avait une pompe. Donc voilà pour vous présenter un peu à Lens. C'est un aérateur connecté et le but, en fait, c'est de pouvoir aérer instantanément son vin sans attendre. Classiquement, normalement, tu vas sortir une carafe pour aérer ton où tu vas l'ouvrir en avance sur ta méthode de production.

Le but, c'est de faire un gain de temps total, c'est à dire que vous ouvrez la bouteille, vous placez la aérateurs, vous scanner l'étiquette. Avec l'application, on règle aérateur et quand vous versez ça instantanément le vin, aérez à la bonne aération et on va faire ça au verre. On n'a jamais touché à la bouteille, c'est à dire que vous pouvez faire un verre à deux heures d'aération, un verre à quatre heures, un verre, un verre à 12h jusqu'à 24 heures et donc, du coup, ça se fait instantanément.

Ça se fait instantanément.

C'est là toute la magie et c'est là où on a beaucoup misé. C'est que de nos jours, quand tu vas recevoir des invités, tu vas vouloir ouvrir une bonne bouteille de vin. Au lieu que tu ouvres, la bouteille ne soit pas à son maximum de potentiel parce que tu n'as pas. Tous les vins doivent être aérés avec plus ou moins une certaine durée d'aération. Là, tu vas pouvoir instantanément ouvrir sa bouteille et déguster le vin dans ses meilleures conditions.

d'Apu, cette notion d'attente et de préparer le vin et cet art de la table, etc. Et qui fait suite à des invités de dernière minute ou juste envie de rire d'une bonne bouteille de dernière minute. Tu peux en profiter directement.

OK, OK, ok, et donc du coup, en fait, si on peut dire tagueur, on peut le faire. Comment ça s'est passé, en fait? En gros, parce que maintenant, tu te retrouves avec Whitey, directeur technique d'une belle boite, mais déjà, t'es super jeune. Et en plus, ce n'était pas ton projet au démarrage. Comment tu? Comment tu te dis que moi, je m'en souviens. Pour les longues discussions, comment c'était dit?

En fait, cette boite là, je vais la suivre, je vais y aller et je sais que il y a un gros potentiel dedans. Technologiquement, le produit est assez bluffant.

Il y a un effet waouh quand tu boot avant après aérations. Donc il y avait ce côté un peu wow. Mais c'est vrai que ce n'était qu'un prétexte et que j'ai démarré stagiaire et j'ai toujours eu ce côté. Il faut arriver assez rapidement dans une boite, ce qui est en train de démarrer et autres pour trouver et avoir un peu le côté touche à tout le pouvoir, monter proprement sa structure, être là depuis le début et poser les bases. Et donc, c'est vrai qu'il y a eu ce petit côté flair où je me suis dit voilà, c'est un produit qui est beau et sexy.

Sur le papier, c'est un beau produit qui est beau, design et qui utilise. J'ai toujours aimé ce côté avoir un produit physique. Que faire du sas ou forcément une solution, mais qui n'est pas forcément palpable. C'est un produit que tu peux présenter, etc. Et donc, du coup, je me suis dit voilà, je vais continuer l'aventure, même si de base, mon ambition, ce n'était pas de devenir directeur technique. C'est un enchaînement de circonstances qui fait que je suis arrivé là où j'en suis.

Mais voilà, je trouve que le produit est intéressant et être à la base de la conception d'un produit. Vu que j'étais très jeune, c'était très intéressant. J'ai appris plein de choses sur. Âge surtout les études qu'on pourrait faire, toutes les normes, etc. Donc c'était très intéressant. Donc, du coup, je me suis dit on se lance dans l'aventure, on va voir où on en est actuellement. C'est une très belle aventure.

Du coup, si on rentre vraiment dans le coeur du sujet et qu'on parle du produit, en gros, c'est quoi un peu les phases Davaine, donc 5 ans avant, quand le projet démarre? C'est quoi les phases? Par les différentes phases par lesquelles vous passez? Comment vous passez d'une bouteille en plastique avec des tuyaux en sortent aux produits Avène, l'opérateur de maintenant, qui est un produit qui, en terme de finition comme tu le dis et à peu près un peu exceptionnel, qui est un produit de luxe entre guillemets.

Et comment vous faites? Comment toi, tu gère ça? Comment tu gère cette dualité hardware software qui est très présente dans cette boite alors que t'es un junior entre guillemets.

Du coup, la boite a été créée en 2007. Donc, comme j'ai dit, le tout premier prototype, c'était c'était la bouteille en plastique avec le tube le fameux et donc déjà, il faut tester. Il faut tester si ça peut marcher parce qu'il faut savoir que le monde du vin, c'est un milieu qui est très réservé et très renfermé. C'est la bouteille, c'est sacré. On y touche pas au contenu du vin, donc, avait beaucoup de sceptiques.

Laperche la faire savoir? La validation d'un monologue, donc. On a demandé tout d'abord à un sommelier, dans un premier temps, Julien, du premier sommelier de France, en élève. Il me semble qu'il est venu donc pour lui montrer notre prototype avec la bouteille en plastique. Donc, déjà, quelqu'un qui pour qui le vin, c'est sacré, tu auras un verre qui sort d'une bouteille en plastique. Il est un peu réticent. Et donc, voilà, il y a des faits.

Si on avait réglé l'aération pour certains vendeurs, on sent vraiment le découplage. Donc là, déjà, on a eu une première validation qui dit voilà si un expert. Si quelqu'un qui s'y connait, il a un effet waouh, il trouve une vraie différence. C'est que le grand public, techniquement, pourrait être conquis, bien sûr, au grand public, très ciblé comme marché. Mais on sait qu'il y a quelque chose derrière un produit qui fait que ça peut marcher.

Donc, à partir de là, tu rentres dans les premières phases, donc tu vas lever des fonds pour pouvoir recruter. Avant ces trucs, on va faire un deuxième prototype il y a un peu plus présentable qu'une bouteille en plastique parce que maintenant, il faut aller voir des investisseurs et des investisseurs. Tu n'impressionnent rarement avec une bouteille en plastique. Donc voilà, tu vas évoluer de fil en aiguille, en prototype comme ça, jusqu'à arriver un peu à une version là où tu temps.

Et une fois que tu as un peu cette phase de démarrage où tu vas vouloir chercher un peu si ton produit va plaire au marché et que tu vas enfin cette validation parce que les investisseurs, parce que les tests, produits, etc. Bah, tu vas voir passer du coup à la production, etc. Donc nous, on est rentré en contact avec un bureau d'études qui Palestinian en ce moment maintenant acteur et qui nous ont aidés à concevoir tout le produit et à entrer du coup sur une plus grosse série à produire.

Vous aviez déjà des prototypes déjà fonctionnels et des choses comme ça avant que vous aviez fait, vous. Parce que tu avais ton équipe, que tu avais monté en interne. Et quand vous allez voir ailleurs? Comme je disais, si une boite, une boite spécialisée dans l'industrialisation exacto avec lequel on travaille aussi et en gros, ils font la grande série. Donc en gros, les mecs sont arrivés et vous ont dit Baumard.

Alors pour faire un grande série, il faut quand on voit ça, ça, ça a été les premiers prototypes. C'était vraiment à la mode. On allait imprimer en 3D des pièces qu'on assemblé, etc. Il faut savoir que c'est un produit, qu'il faut faire de la food et donc, du coup, il y a des contraintes énormes. On a pas mal d'énormes contraintes et que le fait que le produit soit étanche, on ne peut pas techniquement le garantir avec des pièces en l'impression 3D ou en bidouillant des prototypes et même en ajout de fonctionnalités.

On a rien, mais on est vraiment arrivé avec Atchans avec nos prototypes et ils sont conseillés, en est venu à améliorer et conçoit le produit pour quelque chose, qu'il soit industrial et avec la finition qu'on voulait et.

Le temps, c'est un peu la phase de prototype jusqu'à ce que vous avez un peu validé un prototype, validé votre bouteille en plastique qui est vraiment le concept un peu dégueulasse jusqu'au prototype, mais fonctionnel vraiment plus. Ce prototype de présérie quasi donc. Avant de travailler avec un moteur en impression 3D haute, c'est un peu en termes de temps.

En termes de temps, c'est à peu près non. On allait très, très vite en essayer d'aller très, très vite quand on a vu qu'il y avait beaucoup de possibilités pour le projet. Ça nous a pris à peu près deux ans, deux ans en évoluant sur plusieurs prototypes et aussi des prototypes qu'on a co-construire avec Tuor. Mais voilà, on est passé déjà sur plusieurs designs parce qu'il faut savoir que le produit. Au delà d'un concept fonctionnel, il faut un design, parce que c'est un produit qui sur la bouteille, comme tu as dit, n'est ce pas sur quelque chose de vin?

C'est très luxueux et haut de gamme, donc le design est centre dans la conception du produit, indirectement. Donc, il y a eu toutes ces blessures là et ça prend à peu près un an et demi, deux ans, un an et demi, deux ans avant de travailler.

Et après, vous avez travaillé quelques heures. Ça a pris combien de temps pour industrialiser?

Vous avez fait une série de déjà. La toute première série qui est sortie, c'était deux pièces 4004. Vous aviez déjà vendu les trucs. Comment ça s'est fait? On a fait une campagne de crowdfunding sur Inigo, donc les pièces étaient en partie financées, suivant à quel moment tu avais pledge, les remises et les packs, etc. C'est comme ça. Mais voilà, on a, on est un peu KO cofinancer la production du produit parce que quand tu veux d'être en série, il y a beaucoup de choses à prendre en compte.

Donc, du coup, tu vas voir tout l'outillage, tu vas voir tout ce qui est moule pour construire son produit. On a donc, comme j'ai dit, on travaille dans le milieu de la foule. Tu avoir des certifications, des certifications électroniques de base, des composants, mais tu avoir besoin de certification grec parce que c'est quelque chose que les gens ingèrent. Donc, il faut quand même s'assurer que tout va bien. Donc, il y a pas mal de coûts qui rentrent en compte et qui fait que voilà, on a décidé de faire un contre funding pour être sûr que tout le monde soit gagnant et aussi encore un peu ce niveau de test marché puisque, comme je l'ai dit, on avait ces validations là.

Quand on produit en crowdfunding et que des gens adhèrent et que tu a atteint son objectif, tu te dis voilà, c'est le marché. Techniquement, il y a un marché qui, par après, reste Alexandre ou a évalué encore plus. Mais tu sais que techniquement, ton produit rentre déjà dans un marché.

Et donc après, avec Alcorn, vous faites vos protos. C'est quoi un peu le process de travail entre le moment où tu passes? Parce que si on vient un peu en arrière sur la partie prototypage, peut être déjà aussi aussi occupée de la partie seifert application entre guillemets ton couple parce que ton produit en fait à toi, c'est le device, c'est aussi l'application. C'est aussi toute la partie tech qui tourne.

Bon, je sais, je sais.

De source sûre, c'est une vision qui est très intéressante. Toi, t'as jamais fait appel notamment à des clubs de première. Ça veut dire que toi, tu gère tout un service en interne à tes serveurs, tes propres serveurs, tes propres trucs. OK, pourquoi t'as fait ces choix là? Et en terme de dev?

Qu'est ce que ça impliquait alors que, comme tu l'as dit, au delà du produit, on a un service derrière? La première chose, c'était l'ambition de la veine de base de toute base. Le fait d'aérer le vin chaud, c'était de démocratiser le vin. Donc, du coup, on s'est dit voilà, les gens ne bénéficient pas entièrement de leur vin parce qu'il ne l'est pas. Donc, ils ne peuvent pas profiter entièrement de la dégustation. Mais il y a aussi un manque d'information, un manque de culture.

Combien de temps tu devrais direkt maintenant trouver la bouteille quand tu vas acheter chez ton caviste? Hypnotisée à consommer dans telle ou telle température, telle modération. Du coup, on a fait l'application dans un premier temps qui permet de scanner l'étiquette. Du coup, on avait tout ce temps là. Au delà du produit en lui même, il y a toute cette création de bases de données, d'étiquettes et de référencement de vins, etc. Qui est assez complexe que le monde du vin.

C'est quelque chose qui est très, très complexe, avec des codes qui sont différents entre différents pays et autres, etc. Donc, on a tout ce service là et on a aussi développé un point de service avec les pros et donc le coup, tout ça pendant la création du produit, il faut que tu le tienne en compte parce que du coup, ton application va discuter avec l'objet directement. C'est le but d'un objet connecté et donc, du coup, c'était toujours s'assurer d'avoir assez de fonctionnalités pour pouvoir progresser au moment du développement du produit.

Et donc avec Altia. Donc là, vous travaillez. Au niveau structurel, en interne dans l'équipe, j'ai vu beaucoup de changements comment t'as fait pour gérer ça et comment? C'était quoi un peu les répercussions au niveau de l'organisation de ton équipe? Comment est ce que tu organiste en équipe qu'au jour le jour, ton équipe qui produit au jour le jour pour faire en sorte que tout roule?

Donc, effectivement, il y a eu pas mal de restructuration, surtout avec les événements récents Kovy, d'autres, etc. Du coup, ces structures en plusieurs pôles, le pôle technique. Comme je, on a plusieurs gammes de services. J'essaye à chaque fois de donner un maximum d'autonomie parce qu'on est une petite startup, ne faut pas l'oublier. Et donc, du coup, les gens ont beaucoup de compétences transverses et ils vont agir sur beaucoup de points. Donc, du coup, on va avoir un responsable par banc de projet chez Amen.

Comme j'ai dit l'application mobile Android. On va avoir un plan sur tout ce qui va être plateforme web pour les pros, pour nous, en interne, etc. On va avoir la aérateur et donc du coup, on va avoir des personnes qui sont plus ou moins responsables et des développeurs qui sont là en support. Et donc, du coup, vu que l'équipe est assez restreinte, on a des personnes dans l'équipe. Actuellement, on était 4 et on est monté jusqu'à 7 et l'a recruté.

Et donc, du coup, ce qui se passe, c'est que tu vas avoir une même personne qui va être responsable d'un projet. Donc, il va avoir la responsabilité de toute la connaissance de la stack technique et des dépendances et autres que ça peut apporter à la fois de développeur en soutien sur d'autres projets. Donc, il y a vraiment cette notion de transversalité où on n'a pas un seul développeur qui est sur un projet de tout le monde la connaissance entière de la stack.

Ce qui fait qu'à chaque fois qu'on a besoin de faire une modification aussi bien au niveau des protocoles, avec la aérateur autres, etc. On peut répercuter sur tous les projets sans qu'on ait vraiment ce moment de creux en se disant Ah mince, on n'avait pas pensé à ça parce qu'à chaque fois, on a forcément le responsable du projet qui sera là pour dire attention à ça et les autres qui sont techniquement aussi responsables de leur emploi.

Et en termes de stack technique, on a expliqué que leur entrée en texte est ce que tu peux?

Est ce que tu peux expliquer un peu comment ton produit fonctionne? Et ouais, c'est quoi la t'inquietes derrière? Se bah derrière. Juste le petit device. Lequel? On verse 120? C'est quoi un peu la technologie qu'il y a derrière? Je sais qu'il y a des droits de propriété intellectuelle derrière, que tu ne pourras pas forcément diffuser, mais en tout cas, dans les textes, tu peux entrer. Et pourquoi, surtout, t'as fait ses choix.

OK, donc, du coup. Bon bah, l'objet ça, c'est un objet connecté en Bedouce de rentrer plus en détail, donc affiche des propriétés qu'on vient interagir avec les applications. Du coup, on a décidé de les faire en natif. On a deux stacks techniques différentes, une pour Android qui en compte pour iOS et Switch, donc c'est vraiment de différent.

On n'a pas fait vraiment. 2 Pourquoi t'as pas fait un réadmettre si fait ça? Il y a plusieurs choses. La première chose, c'est qu'on a Avène. On est né. C'est une boite tech et donc du coup, on ex-proche la tech et on s'est dit voilà. iOS et Android, c'est deux mondes différents. On ne veut pas d'un produit utilisateur. Est ce cette même expérience? Parce qu'il y a des expériences qui sont très différentes quand on trouve même des applications de base entre Android et iOS.

Donc, vous voulez vraiment créer cette distinction sur lui? Petit détail, mais qui fait toute son importance. Et l'autre choix? On rentre parfois dans de la complexité puisque, par exemple, on va mettre à jour l'objet via son téléphone. Et donc, du coup, il y a un moment, on va rentrer dans des stacks techniques où on va communiquer en Bluetooth avec l'objet où on s'est dit on ne veut pas être bridé, on ne veut pas perdre du temps dessus et on préfère avoir la main dès le début dessus, qu'on a une boite traitais et que ça nous fait pas peur, littéralement.

Et donc, du coup, on va rentrer dedans. Et donc, ça nous permet à la fois de rajouter tous ces petits détails d'expérience utilisateur qui sont pour nous très important et à la fois d'avoir un contrôle total sur ce qui se passe en interaction avec l'objet et ce qu'on veut faire en interne sans avoir de limitations techniques.

Je ne pense pas que ça vous a retardé. Si, si. Ça nous a beaucoup retardés et même indirectement, à chaque fois qu'on va sortir une formalité, c'est à dire le double travail de développement en termes de ressources humaines, ça veut dire qu'il faut gérer deux projets. Donc, s'il te faut une semaine pour développer une fausse qualité sur une plateforme, techniquement, il te faut deux semaines ressources humaines. Donc ça prend beaucoup de temps. Mais c'est un pari qu'on comprend pour l'avenir.

Voilà une petite startup, ça peut être coûteux, mais quand ça va grandir et qu'il y aura une vraie équipe, etc. Qui peut au contraire être très productif et qui peut rapporter beaucoup en termes d'expérience utilisateurs et même de coûts de développement.

Indirectement, et du coup, tu parlais de faire un MD de ton objet connecté en Bluetooth. En gros, pour entrer dans le détail technique, tu fais un autre ordi. Et donc, du coup. Comment tu commences tu, comment vous avez entre guillemets? Parce que comment vous avez eu la clairvoyance au démarrage de vous dire on va avoir ça? Il va falloir faire 2 2 applications différentes.

Du coup, comme je l'ai dit, on est très t'inquietes et donc du coup, on s'est dit on ne va pas répéter les erreurs qu'on a déjà vu sur certaines choses. Tu prends des applications type, etc. On a vu qu'il y avait des erreurs parce que justement, ce développement, comment vas tu?

Ça vient que de votre culture technologique. C'est un vrai côté culture. On s'est dit on veut donner le maximum à l'utilisateur. C'est l'utilisateur est au centre de notre excellence que nous propose une expérience, l'expérience. Et donc, on voulait vraiment se démarquer littéralement de la concurrence que tu prends. Application regarde concurrent Divino qui peut être classique, donc, du coup. Vous voulez vraiment démarquer ça? Et le coût de la mise à jour? Donc, en diffusant en Bluetooth, c'est parce qu'on a embarqué assez tôt qu'on ne se mettait pas trop d'accord en interne.

Et donc, du coup, à n'importe quel moment, il fallait potentiellement qu'on puisse mettre à jour des comportements aérateur, qu'on a prévu la fonctionnalité. Et ça nous a notamment pensé au tout début. Tout au début, sur les premiers aérateur, on pouvait pas. Il n'y a pas de bouton on off sur les attendre qu'on ne pouvait pas les temps. Notre utilisation en interne, c'était laisser la aérateurs sur le socle en charge. Dès qu'on a besoin, on prenait, on faisait service, remettait dessus et on s'est très vite rendu compte que des pros et des particuliers avaient le besoin ou l'envie de se balader avec leurs aérateur.

Sauf que, du coup, l'écran reste allumé. Tout restait allumé en permanence, donc la batterie fonder une allure pas possible. Et donc, du coup, on a vu qu'on avait anticipé ce besoin avec la passivité mise à jour. On a implémenté un mode de veille qui, au bout de 2 minutes, éteint l'écran qui passe par l'écran tactile. Mais si on n'avait pas pensé à ça dès le début, tu as potentiellement deux mille produits qui déplaisent à l'utilisateur.

Ce que tu n'avais pas prévu de leurs besoins dès le début, c'est ça.

C'est super intéressant. Bon, on en parlait tout à l'heure, mais quand tu démarre avec un Alcor ou n'importe quel industriel, en fait n'importe quel industriel. En fait, quand tu fais une industrialisation, c'est une grosse machine qui se met en route. Et une fois que t'as fait des choix, tu fais tes choix. Mais ton produit met un an quasi à sortir entre le moment où tu fais tes choix et le moment où le produit, ça fait un an.

Donc tout l'intérêt de. Prévoir un peu de te dire qu'est ce qui peut se passer en général, mais clairement, ce que les bonnes pratiques, c'est de dire, on va pouvoir faire un objet différent. On essaie de bien pousser les choix en termes de hardware pour pas avoir à changer les cartes électroniques et autres. Par contre, on fait tous les aider en terme de fonctionnalités au niveau du firmware, exactement comme au niveau de l'industrie de l'assurance.

Et là où tu fais tout, c'est arrivé pour voir tous ces problèmes là en amont. Mais en effet, le fait d'anticiper fait que quand, quand tu as un produit que tu n'as pas vu ces temps ci, patience sur des problématiques qui peuvent arriver. Si tu produits un trop gros batch, c'est un batch qui peut potentiellement être perdu indirectement parce que tu tapes tape à la main en cas de problème. En cas de défaillance ou en cas de comportement que tu n'avais pas prévu de pouvoir corriger le tir.

Et donc, du coup, vous, vous, quand vous faites comment vous faites, quand on fait une pièce, ça vous coûte?

Ça vous coûte un million et demi de pièces? 38 millions? Oui, mais la trésorerie de sa start up, ça coûte très cher et ça coûte très cher sur toutes les 2015. Au tout début, comme j'ai dit, il faut acheter l'outillage, les moules, les certifications. Ça, ça, c'est un vrai premier coup et c'est un décaissement de trésorerie que tu ne récupère que plus tard, qu'une fois que tu avances du produit. Donc, c'est un pari.

C'est un énorme pari. Quand tu sors un de ce qu'il faut que tu dises voilà, je sors des pièces, il faut qu'elle soit fonctionnel, il faut que j'arrive à les vendre, sinon, je ne me rembourse pas moi même. Et donc, du coup, tu as ce décaissement de trésorerie qui fait que ça joue un peu avec la vie de la boite.

C'est chiant, c'est chiant, mais en plus, on se connaît bien, donc je le sais. Mais vous avez été un peu en galère à des moments parce que. Et comment fait toute boite hardware qui anticipe pas trop ce truc là? C'est qu'en fait, si t'as un retard dans la production des utilisateurs, ils payent une fois qu'ils reçoivent le produit. Et toi, tu dois payer des fournisseurs avant d'avoir avant de Schippers, donc à une grosse galère.

T'as besoin de cash au moment où les produits doivent sortir de l'usine parce que les industriels, lui, s'en foutent. Que vendu les produits de skimming, c'est que quand les produits sortent de l'usine, ils soient payés parce que sinon après, derrière la débrouille toi utilisateur, ils payent un client, ils payent quand ils ont produit chez eux. Nous coiffait entre les deux tablettes deux mois ou trois mois de bateau. Pas de transport de douane, de machins de choses.

Et pendant ces deux mois là, on fait un trou de trésorerie qui est énorme, trou de trésorerie qui est énorme.

Et même une fois, quand ils sont réceptionnés parce qu'il faut quand même écouler les stocks, on kodama. On avait fait la campagne nigo, donc les produits étaient déjà vendus et déjà payés. Mais après, pour le reste, voilà, c'est ça. Toi, tu te retrouves avec des produits dessus, tu peux ou tu peux voir. Tu vois que tu as des cartons remplis dans tes bureaux de aérateur et là, il y a toute une fortune. Mais malheureusement, il faut les vendre et c'est un autre processus qui prend du temps.

Et les questions sont un peu décousues parce viennent au fur et à mesure du fric.

Mais du coup, à ton propre serveur en interne chez toi, pourquoi tu n'as jamais voulu utiliser des plateformes cloud, un cloud provider et pourquoi tu te fais chier entre guillemets à maintenir un serveur?

Alors on a des serveurs en interne pour le tout début de l'histoire. C'était l'ancien directeur technique qui était très pointu et c'est vrai que ça nous a servi. Quelquefois, c'est déjà pas cher. L'amortisseur Jaccoud, il y d'un point vue sécurité parce qu'au moment de la RFD, vu que c'est un produit qui est totalement innovant, on voulait absolument pas qu'il y ait quelque chose. Kilic et donc du coup, en fait, avoir les serveurs en interne, ça nous a permis de structurer tous nos outils en interne pour être derrière et protégé, inaccessible de l'extérieur.

Et après? En fait, on s'est rendu compte que finalement, la charge que produisait l'application et même les services qu'on met autour, etc. N'était pas si grande. On n'a pas beaucoup d'utilisateurs et donc du coup, ça nous permet de contrôler les coûts indirectement, car on l'a dit, il y a quand même des questions de trésorerie et autres, etc. Ça nous arrive des solutions à WS pour pouvoir palier certaines choses, notamment tout ce qui va être la destruction de ressources sur trois autres, etc.

Pour des ascètes statiques, etc. Mais on a assez cette volonté de garder les serveurs et ça nous permet aussi d'avoir un environnement qu'on peut dupliquer. On a plusieurs phases de développement, donc on va avoir une phase de dev. On va avoir une phase d'alpha en interne où on va pouvoir tester, nous, en interne, les modifications, ce qui s'est passé au delà de l'équipe tech, tout le reste de l'équipe. Appréhender les choix techniques et business prévoit une phase de bêta, on va ouvrir, etc.

Et donc, du coup, ça nous permet d'avoir vraiment cet environnement découpé, mais qui est similaire et qu'on peut passer à le faire chier n'importe quand.

On peut le faire chez n'importe qui, avec le travailleur. Le seul problème, c'est que c'est des machines qui ont de tout temps et que du coup, parce que comme j'ai dit, on les a pas eu et mortis directement l'héritage.

T'as juste un costard, juste un coup d'électricité. C'est juste une question de l'opportunité s'est présentée. Vous auriez pas eu l'opportunité d'avoir ces machines? Vous serez sûrement sera un propriétaire normal. OK. OK, OK, ok. Et en terme de développement, c'est quoi un peu votre steak? Tu nous a parlé de tests techniques sur la partie, sur la partie. C'est quoi un peu? Acte technique et les choix techniques que tu as fait pour la partie plutôt backend?

Serveurs et autres Jean-André vont dans le technique. Pas vraiment leur technique.

Mais expliquer que tu donnes pourquoi t'as fait ces choix là?

Vis à vis d'une techno, par rapport à une autre, il faut savoir que la stacking Caven, elle, a beaucoup, beaucoup évolué. Y'a un moment, c'est trop avec.

Explique pourquoi.

Au tout début, l'ancien directeur technique avait une vision assez particulière de langage à but et un but très précis.

Et du coup, on arrivait sur quelque chose avec 7 langages différents. Donc, on avait un langage différent pour les deux applications. Donc déjà deux. On avait un langage codé API, un autre. On avait un langage pour des micro services, encore un autre. On avait un langage proche du traitement de données. Comme j'ai dit, on a toute une base de données sur le va faire du travail. On en avait encore un autre. Donc voilà donc ça se multiplier.

Et startup avec une petite équipe, si tu veux vraiment pouvoir pousser le langage et vraiment pousser les retranchements. Sept langages, ça commence à devenir compliqué par équipe de trois développeurs. Souvent, c'est you.

Moi, je me demande. Moi, je me demande encore, mais je sais que je sais que qu'un un aliènent. Mais je me demande encore comment il maintient. Cette affaire est termine avec une si petite équipe.

À ce qui s'est passé, c'est quand on a commencé à A, une fois qu'il y a eu un peu ce changement d'équipe, etc. Que du coup, j'ai repris. J'ai dit voilà. Les langages, certes, ont des spécificités, mais pour ce qu'on fait 81% d'un usage global, tu peux prendre n'importe quel langage. Tu vas répondre à ton besoin, ce ne sera pas le top de la performance, etc. Mais il vaut mieux que ton développement soit rapide parce que ton équipe est à l'aise sur la stack technique, que de prendre le truc parce que c'est le top du top, que ça fait tant de performances et que tu trouveras pas mieux ailleurs que toutes les équipes se forment.

En plus, c'est quelque chose qui n'est pas retenu, qui n'est pas beaucoup utilisé, etc. Donc du coup, ça a beaucoup changé. Donc maintenant, on est sur quelque chose de relativement stable, donc on a du coaching sur la partie des API, ce qui nous fait maintenant un langage commun entre l'application mobile, etc. Du coup, à des personnes qui sont à l'aise à la fois sur application mobile en coating même s'il y a des spécificités pour Android, peuvent intervenir ensuite pour la partie backend des micro services, donc est sur une architecture micro services avec des API qui relèvent juste.

Je pense que on a pris un pari. C'est un très bon développeur avec qui je travaille depuis le début de mes études à Epita, qui travaille à Rennes, où on est passé en cristal. Et là, pour le coup, là, c'était vraiment un choix de langage pour la simplicité et autres, etc. Qui fait que maintenant, on a une sacrée vie qui est très simple parce que du coup, on en a plus que 4. Comme j'ai dit 2 fois du code ligne du Swift et du cristal pour du backend.

Et après? Bien sûr, tout ça avec de l'administration système classique. Mais voilà, on est revenu sur une stack technique plus simple qui fait que tout le monde s'y retrouve plus simplement. Et après, si j'oublie, on a aussi les applications Web qui sont fait en JavaScript, avant même Borgias plus particulièrement. Mais on a vraiment eu ce retour où je me suis vraiment éloigné de cette vision. Il fallait un langage par stack, par projet, parce que c'était le langage, etc.

Et vraiment revenir à ce côté. Il faut que ton équipe soit à l'aise au moment du développement si tu veux que ça avance. Si ton équipe prend trop de temps à se documenter, à se poser des questions, à comprendre les best practices, tu vas rentrer dans du spaghetti et tu vas au contraire perdre en performance sur le langage parce que tu vas, tu ne sais pas comment l'utiliser. Tu vas, tu vas te tirer vers le bas toi même, en fait.

Comment d'organiste ton équipe maintenant? ES une petite équipe de quatre, cinq personnes? C'est quoi un peu votre organisation? Au jour le jour, la semaine au mois? En gros, comment vous organisez vous? Faites du scrum ou utilisez Boba Fett.

On est très fan de la station spatiale, très fan. Bon, malheureusement, ils ont arrêté leur support serveur. Je pense qu'on se séparera bientôt. Donc, on fait du scrum, donc en fonctionnant en sprint de deux semaines. On essaye d'assurer des livrables toutes les deux semaines. Du coup, la fin du sprint. On décale les phases de cycle. Comme j'ai dit, on a 4 environnements Alpha Dev, Alpha, Beta Prod. La fin de semaine, on décale tout d'un cran, ce qui nous permet d'assurer toujours avoir une fonction était au niveau utilisateur pour éviter qu'ils s'ennuient, de nous assurer que le déploiement continue est toujours bon, etc.

Et donc, du coup, au jour le jour, ce qui se passe, c'est que du coup, au début, on va préparer les tâches, etc. Et à chaque début et fin de Spring, on va se poser certaines questions sur l'impact que va avoir certaines tâches. Parce que, comme je l'ai dit, on peut très vite changer si on prend une modification sur quelque chose qui est assez complexe, comme la structure du vin, des relations entre tes domaines, les vins, les régions, etc.

Le problème, c'est que si tu vas vouloir changer ça en base de données, tu vas devoir respecter tout technique. Il y a une grosse problématique. On a appris à nos dépens très récemment. Récemment, les applications mobiles posent beaucoup de soucis parce que les gens ne mettent pas forcément à jour leurs applications mobiles et donc du coup, si tu changes pour format de données, il faut que tu supportes certaines anciennes versions d'applications mobiles, le temps que les gens mettent à jour leurs applications.

Je ne peux pas forcer la mise à jour des applications. Je ne peux pas forcer. Il y a des applications où tu lances, tu n'as pas la dernière mise à jour, mais techniquement, tu ne peux pas forcer. Et donc, du coup, tu as un côté où tu veux quand tu vas vouloir faire une transition vers un modèle de données. Il faut que tu fasses attention et donc, du coup, ses débuts en sprint, ces moments là où on se dit attention, on ne va pas casser quelque chose.

Donc, c'est là où on a beaucoup utilisé en interne, c'est à dire beaucoup. Sémantique versus Hanning. Avec le fait que s'il y a une version majeure qui change, ça veut dire que c'est plus du tout compatible et on s'arrête là.

Donc, du coup, au jour le jour, on se retrouve le matin, on va discuter un peu des tâches, un peu comme un délit briefing pour voir un peu où les gens avancent, dans quelle direction, etc. Et les gens sont assez autonomes dans leurs tâches et qui a besoin. On va pouvoir interagir avec les autres, surtout en cette période de pandémie. On est tous en télétravail. On est sur, on est sur discorde et on discute tout le temps.

Donc, faisais discordant en interne, on n'ose pas dire que c'est là qu'on va.

Vous êtes une boite extérieure, ce même de la tête.

OK, ok, ok. Et donc, du coup, quand tu l'as, la slack, la stack Atlassian. Putain, j'ai du mal.

Tu utilises Jira aussi pour le Project Management, c'est vraiment total, donc on agira pour le project management, pour tout ce qui est Petiquay, les sprints, la rétrospective, etc. On a confiance en interne pour toute la documentation, donc l'objet. C'est quand même quelque chose de complexe. Donc il faut garder une trace des protocoles Bluetooth quand on veut mettre à niveau d'aération, quand on veut récupérer des niveaux de batterie, etc. Donc, on a tous ces protocoles là, même en interne, de la documentation technique.

Comment certains marchent en marche, certains projets, d'autres, etc. On a 2 4 pour stocker tout ce qui est code et on fonctionne beaucoup. Comme j'ai dit un peu en intégration continue et en déploiement continu, donc à chaque modification du développeur, à chaque chromite. On va avoir un build de la branche pour nous assurer que le projet fonctionne correctement, ce qui va permettre. En fait, il y a des moments où tu vas vouloir tester des fonctionnalités, mais sans que ça arrive forcément sur ta branche de développement, d'être sur que tu puisses récupérer ça et que ce soit fonctionnel parce que ça a build, parce que tes espaces, etc.

Et donc, du coup, le fait d'avoir utilisé Atlassian de long en large, ça te permet beaucoup de choses? Ça permet de Balcaen. Tu vas arriver sur ton code et que tu vas dire OK, j'ai fini cette société là, je regarde Apple Requests et automatiquement, tu vas avoir du coup le ticket Equilis avec toutes les descriptions, toutes les dépenses qu'il pourrait avoir. Tu veux avoir ton Bembo qui va te dire OK, ça passe, tu peux.

Mergeai, ça build pas. On ne peut pas Mergeai, donc on n'avance pas. Et ça permet aussi, du coup, comme je l'ai dit, d'arriver en production et être sûr que le code est testé est fonctionnel. Et Sabine n'a pas la surprise du moment du déploiement. Bizarrement, quelque chose est passé au rouge.

Ça arrive de temps en temps, mais c'est vraiment rare de voir valider vraiment en amont et en détail un tout petit peu, parce que des gens ne pourraient pas forcément comprendre. Donc, en gros, Christophe, par la suite, Atlassian Nathanson, c'est une grosse boîte américaine qui fait des outils pour des développeurs. Donc ils ont plusieurs tools, ils ont Jira et qui fait du Project Management Bilboquet, qui est l'équivalent du CAB, GitHub qui offre un système de gestion de version longue.

Gestion de versions du code.

Et vous utilisez confluents la documentation en interne. OK, quand on merge poule ou machins. Tout ça, c'est du vocabulaire qui est propre à GUID Guide. C'est le système de gestion de versions. En fait, à chaque fois que quelqu'un développe quelque chose, il va faire une merge request. En gros, il va demander à ajouter son code à une base déjà existante. À l'intérieur de tout ça, il y a des fois, on peut voir ça comme un arbre généalogique avec un arbre généalogique, avec différentes versions qu'on appelle des branches, comme un arbre.

Et du coup, on va Mergeai sur la branche de l'endroit.

Et à chaque fois que le développeur, du coup, fait une modification, on a pris une note interne et on trouve assez bien. C'est qu'on va mettre le numero du ticket caché que n'importe quel moment. Si on voit qu'il y a un, il y a une modification. On peut voir quel ticket a engendré, pourquoi on l'a engendré avec des relations et on peut très vite remonter sur un bug.

Vous êtes très data Orientis dans votre développement aussi sur de l'information. Et vous, Giada, un système de gestion de l'info qui est un peu solide. Moi, c'est ce qui m'a toujours impressionné. Comme je cite avec ces données, vous êtes une boite de 4 personnes, vous gérez comme s'il avait deux morts.

Si vous avez 40 personnes, ça marcherait pareil quand c'est vraiment le truc un peu fou, un peu fou chez toi, dans ta vision de l'ingénierie, pour rebondir sur ce côté, comme tu dis data driven, on a quelque chose dont on est assez fier en interne et qui nous sert beaucoup, notamment pour monter les problèmes. Comme j'ai dit, la stack est assez complexe, a beaucoup de choses qui passent, etc. Donc, en interne, à chaque fois qu'on a des utilisateurs qui font des requêtes, on va générer ripostait, dit on en interne.

On a un énorme stack lolcats avec un énorme cabanas où tu vas juste mettre la requête et tu peux roten ça pour les gens.

Parce que du coup, à chaque fois que l'utilisateur va faire une. Expliquer à ta grand mère le canard à chaque fois que l'application va faire une demande au serveur. On a un identifiant de la requête qui est généré, un identifiant unique à chaque requête et non en interne. On a un très beau système. On a passé beaucoup de temps à Épaulières, mais qui fait que maintenant, c'est très fonctionnel ou à partir de l'identifiant. Là, dès qu'il y a une erreur, on peut remonter l'identifiant et on peut retracer tout le chemin de la requête avec toutes les interactions qu'il y a eu.

Du coup, quand on détaille un peu aussi, le but des micro services, c'est d'avoir plein de petits serveurs. Petit service découplé et qui fait qu'ils interagissent beaucoup entre eux. Et c'est parfois assez difficile de trouver là où ça aurait pu casser ou quelle est la suite d'événements qui auraient pu engendrer ce problème. Et donc, du coup, c'est assez pratique qui est une erreur. Qu'on ait un identifiant sur le support, on communique juste l'identifiant et on peut remonter tout de suite.

Enfin, l'origine du problème et le corriger très rapidement en production. Comme on l'a dit, on a une exigence envers le consommateur et on veut donner un produit et un service de qualité qui fait que dès qu'il y a une erreur, dès qu'on a détecté une erreur, il faut qu'on interagissent tout de suite pour pouvoir corriger l'erreur et que l'utilisateur retrouve son expérience.

Génial, génial et bon. On a fait un peu le tour de toute ton expérience, mais toute mon expérience. C'est quoi un peu la méthode Christophe Packard pour développer un bon produit à la fois d'un point de vue utilisateur, d'un point de vue technique? Vraiment un truc un peu transversal. Si tu veux le découper en fonction des phases de l'entreprise, tu peux.

Mais globalement, moi, j'ai envie de savoir les 3 4 trucs qui font que les produits de Christopher Packard sont toujours des excellents produits.

La recette magique, magique. La première chose, comme on l'avait dit, je pourrais insister dessus parce que ça nous a sauvé la vie. On s'en rend compte. C'est vraiment identifier les potentiels futurs problèmes et mettre dès le début des solutions en place, comme on l'a dit pouvoir mettre à jour, etc. Donc, au niveau de la conception du produit, voilà, ça va être de garder de l'agilité. C'est se garder de l'agilité, c'est se garder une marge de manoeuvre, soit se fermer des portes exactement, ne pas du tout se fermer des portes.

Et donc, du coup, tout ça pendant la phase de conception du produit, c'est se poser les questions. Faire des tests avec de potentiels futurs utilisateurs, donc, nous dit on, avait besoin de validation de nos logs et de sommelier. Donc du coup, c'est eux qui nous ont servi, a aussi un peu à ça. Dont tu as toute cette partie là sur ta phase de conception, sur la phase de production, ça va être de faire très attention sur les premiers produits qui sortent usines, de s'assurer que la chaîne de montage, l'outillage, tout convient bien, que les produits que tu reçois sont corrects.

Donc tu vas voir un contrôle de qualité qui est top parce que si tu valides quelque chose qui est pas top en industriel, il va dire OK, il va produire 2010 2013, chose qui est fatale, donc du coup, donc, il faut vraiment faire attention. Cette phase là, c'est ça tuilière. Ça a à aller en Chine. On avait fait un voyage en Chine, on allait voir dans les usines et donc du coup, on était là.

On définit une liste de défauts acceptables. Du coup, on se dit voilà, il y a plusieurs phases aérateur. Alors, la face avant la face sur les côtés, on se dit voilà, on ne peut pas avoir des rayures qui sont plus grandes de 0,2 mm et ainsi de suite. Si l'on attribue des notes et aérateur est en dessous d'une certaine note, il passe pas le contrôle qualité et on n'accepte pas la pièce.

Donc vraiment cette définition du process ISO pour faire valoir ce contrôle qualité. Et une fois que le produit est en place, il ne faut pas s'arrêter. C'est le début de l'aventure. C'est le début de nous. On a sorti un deuxième produit très récemment pour s'adapter justement au retour du premier produit. Et donc, du coup, il faut être très agile sur tes retours utilisateurs et vraiment écoutés utilisateurs parce que l'utilisateur sait si on regarde un produit financier. C'est ton marché, ce qui va te permettre de survivre, qui fait que voilà.

Mais voilà, COCAN, comme je l'ai dit, on est une boite technique qui tient à vouloir mettre au centre l'utilisateur dans son expérience, etc. Et donc, c'est important d'écouter son retour et de lui apporter le maximum. Donc, comme je l'ai dit, on n'avait pas prévu de bouton en off, il n'y avait pas de veille. On a implémenté la veille l'application, il y a des choses, etc. On met à jour et ainsi de suite.

Donc, c'est pour ça. Il faut dès le début ne pas se fermer de portes. Et après? Justement, avec toutes ces portes ouvertes.

Travailler avec l'utilisateur pour pouvoir les entretenir et améliorer le produit vers quelque chose de bien intégré.

C'est intégré, sont vraiment intégrés son client, son utilisateur dans la conception et dans le développement. Est ce que tu as quelque chose à rajouter, quelque chose que tu veux pas? Tu recrute quelqu'un, perpère?

Je ne sais pas. En vrai, la période est un peu difficile. N'hésitez pas à on sait que les gens sont un peu sceptiques sur produits, donc on a fait un concept qu'on appelle les ambassadeurs. Bon, maintenant, ça marche un peu moins. C'est les restaurateurs qui utilisent le produit au quotidien. On peut les trouver directement depuis l'application et notre site web. Du coup, ça permet de tester le produit quand il rouvrira, bien sûr.

Mais voilà, le vin, c'est quelque chose que moi, je m'identifiais. Pas du tout comme quelqu'un qui pourrait boire du vin. En fait, on apprend à l'aimer, etc. Et c'est vrai que c'est ça. Ça paraît bête, mais ouvrir sa bouteille quelques heures avant la carafe, ça change entièrement l'expérience. Et du coup, je peux vous conseiller si vous n'avez pas la aérateur d'ouvrir votre bouteille, votre carafe avant et sinon de vous faire plaisir sur un cadeau de Noël ou d'anniversaire à se faire.

Vous avez bien compris, allez acheter un dispositif. J'ai pas d'actions, eux. Beau, ben allez, merci Christophe CTG merci à toi, c'est avec plaisir.