Le 26 Mai 2023, j’ai eu la chance de participer comme tous les ans au Devfest de Lille. Fini le Kinépolis, le Devfest a déménagé à Lille Grand Palais. Un super endroit, professionnel, accessible en transport, avec un espace partenaire immense ! On s’est senti à l’aise, et je ne doute pas que ça va donner des idées aux organisateurs pour les futures éditions. Une démarche éco-responsable, sans accroc, vraiment toutes mes félicitations aux organisateurs, c’est toujours un plaisir de retrouver l’écosystème Lillois.
Et cette année, pour la première fois, j’y étais présent en tant que conférencier.
J’ai pu partager un retour d’expérience sur ces dernières années chez Karnott, l’écosystème des startups, et les difficultés organisationnelles que nous avons pu rencontrer dans un contexte de rentabilité. L’occasion de raconter ce que nous avons collectivement mis en place, et j’espère de fournir quelques ressources utiles.
Le 1er juin 2022, j’ai fêté mes 5 ans chez Karnott. Mon idée initiale était de retranscrire mon aventure en startup sur ce blog, avec un article par an.
Vous l’aurez compris, l’an 4 s’est perdu en cours de route. On va essayer de rattraper ça.
2021 a été une année en deux parties très contrastées pour nous. Vous n’aurez pas raté l’actualité de la Frenchtech: année record, avec plus de 11 Milliards d’Euros de levée de fonds. Et quand on est en startup, cette capacité de financement fait franchement envie. On s’est dit collectivement que c’était le moment et qu’il fallait profiter de la dynamique… Pourquoi pas nous ?
La préparation d’une levée de fonds
Une levée, c’est beaucoup de travail. En travail de fond, on s’assure qu’on n’a rien à cacher: sécurité des données, contractualisations avec les prestataires, propriété des éléments clés, code source à l’abri. En parallèle on travaille sur le plus important : le pourquoi. Pourquoi ai-je besoin d’argent dans mon équipe produit ? Une levée, c’est avant tout une équipe qui convainc des investisseurs qu’ils ont une vision, mais manque de moyens pour y parvenir au plus vite. On a besoin de cet argent pour embaucher, se structurer, pour accélérer. Nous avons donc construit notre vision produit court / moyen terme / long terme et nous avons mis sur papier la meilleure manière de l’atteindre si nous avions les moyens de nos ambitions. On parle de SaaS, d’une gamme de produits, de feature teams. De qui aurions-nous besoin, quand est-ce que nous devrions embaucher chaque personne, combien ça nous coûterait, etc… Le business plan sera aligné avec cette vision produit. Une feature team qui arrive ne produira de la valeur que X mois après, il faut aligner les planètes.
Et quand on a compris ça, on comprend un peu mieux ce qu’il s’est passé en 2021 dans les embauches et les salaires de la tech française.
Pour suivre le business plan établi lors d’une levée à plusieurs dizaines ou centaines de Millions, beaucoup de startups ont eu l’obligation d’embaucher vite vite vite, comme promis aux investisseurs. Comment on fait ça ? On paye au-delà du raisonnable. Les salaires ont franchement explosé dans certains cas. Je sais que cet avis n’est pas très populaire, vous entendrez que les salaires ont augmenté en 2021 pour d’autres raisons. Je peux citer, entre autres choses : – les boites françaises sont en concurrence dans le recrutement avec les boites étrangères, le remote se démocratisant. Et à l’étranger, ça paye mieux. – les boites françaises avaient de toute façon du retard – C’est juste la loi de l’offre et la demande mon bon monsieur.
C’est sûrement en partie vrai, mais je pense que c’est avant tout le cumul de ces raisons avec un afflux massif de capitaux, en plus d’un marché de l’emploi historiquement tendu dans la tech pour les profils qualifiés.
À titre personnel, c’est une situation que je n’ai pas très bien vécu, n’ayant pu retenir un des membres de l’équipe.
Et donc ?
Et donc, nous n’avons pas levé malgré des propositions reçues, les termes ne nous convenant pas. Une bonne levée est une levée au bon moment, où tu te sens prêt à accélérer dans de bonnes conditions. Cela faisait 4 ans que nous avions la tête dans le guidon, nous avions accompli beaucoup de choses, mais une intuition nous laissait penser que pour lever dans de bonnes conditions, nous avions besoin d’assainir nos fondations. Un autre chemin était possible : celui d’être rentable et autonome.
Une startup rentable ? Vous êtes sérieux ?
Oui, c’est possible et on est même en train de se dire qu’on a eu le nez fin. La guerre en Ukraine, les conséquences long terme du COVID en Asie, les galères d’approvisionnement, l’inflation… Les investisseurs sont en train de serrer la visse et lever n’est plus aussi simple. Gare aux entreprises qui vont avoir besoin de fonds en 2022 ou 2023 !
🚜 La bonne nouvelle pour nous, c’est qu’on a plein de super clients ! Karnott, ce sont des milliers de clients, des dizaines de millions de Kilomètres parcourus et des millions d’Hectares travaillés et analysés avec notre solution. On en est fier et on a raison de l’être. Bref, la rentabilité n’est pas une chimère lointaine… C’est faisable, on y croit.
Cela étant dit c’est aussi une trajectoire diamétralement opposé à ce qu’on avait planifié ces derniers mois : du jour au lendemain, on prend notre jolie roadmap, nos plans de recrutement de 50 personnes et on met tout de côté. Moralement, ça fait quelque chose…
L’idée est donc de réduire les coûts et de maximiser la croissance. Comme toute entreprise me direz-vous ? Non. En 15 ans, dans la tech, j’ai rarement vécu dans un environnement technique contraint financièrement. Dans l’aéronautique, le bancaire, le retail, j’ai toujours travaillé dans des environnements où on regardait peu les coûts techs, qui étaient pris comme une fatalité pour aller où on le souhaitait. J’ai souvent trouvé ça malsain et étrange, sans arriver à comprendre ce qui n’allait pas. La réalité, c’est qu’à petite échelle, le retour sur investissement d’une équipe produit est quelque chose de quantifiable. On voit les salaires, les coûts SaaS, les coûts d’infrastructure, on mesure l’argent qui rentre par la valeur produit générée et on doit constater un tout cohérent. Tout simplement.
En tant que CTO, j’ai eu plusieurs défis.
1er défi : Le FinOps
Mes camarades le savent, je suis pénible sur la gestion de l’infrastructure. Le Cloud, c’est cool, mais on est toujours à 1 clic de la dépense facile. Et bien non, au diable le Darwinisme Numérique et son abondance (interview passionnante cela dit), la sobriété a du bon. On passe du temps à optimiser l’utilisation du CPU réservé, des services qui tournent, de l’espace disque alloué. (Saviez-vous qu’avec TimescaleDB il est simple de compresser les vieilles données ?). C’est un travail, mais je suis certain que tout ce qu’on a appris et mis en place nous donneront des clés de scalabilité et de pérennité.
2nd défi : Gérer toujours plus, avec les moyens du bord
OK, l’équipe ne grandit pas. Pourtant, nous avons de nouveaux clients, plus de données, plus de défis. Mais aussi plus de support. Arriver à créer de la valeur avec un support chronophage devenait impossible. Alors on se calme, on qualifie mieux les tickets, on mesure et on se concentre sur ce qui cloche. On s’est vite rendu compte que le support reposait sur quelques épaules et qu’individuellement on n’avait pas toujours la compétence requise pour résoudre le ticket. Alors nous avons mis en place des astreintes : chaque jour de la semaine, un membre différent de l’équipe est forcément de support et il doit documenter ce qu’il fait. Cette journée-là est dédiée à dépiler du ticket pour la personne d’astreinte. Obligation aussi de laisser des commentaires, au moins un début d’analyse et un travail en cours pour la personne du lendemain. On se partage le travail et les soucis. Cela a permis à l’équipe de mieux prendre conscience des problèmes de qualité, d’outillage interne manquants, d’en prendre acte, de coder quelques « helpers » et en quelques mois, magie, le nombre de tickets a été divisé par deux.
J’ai écouté d’ailleurs un super podcast avec Mathilde Lemée qui parle de sur-qualité et du fait qu’il y a un temps pour tout dans la vie d’une startup. Je ne peux qu’appuyer son propos.
Conséquence directe : nous avons toujours été en capacité à délivrer de la valeur (et donc du MRR), avec une certaine sérénité sur la qualité de ce qui était délivré.
3ème défi : Faire plus avec moins n’est pas sans conséquence
Comme je suis sympa, je vous partage ma recette d’un petit cocktail maison : – Un objectif d’entreprise clair à atteindre à tout prix – Une équipe à qui ça tient à cœur de réussir – Le télétravail, qui rend plus floue la coupure travail / vie de famille – Une communication entre les services plus basée sur l’émotion que sur les chiffres et les faits – Des résultats avec des bons jours… et des moins bons.
Et vous avez la recette pour un petit burn-out.
En mai 2022, j’ai ressenti une profonde fatigue. Du genre à se sentir vraiment nul, toujours énervé, grincheux (plus que d’habitude :p ) et surtout impuissant à réussir. Heureusement pour moi, j’ai pu très vite compter sur ma compagne qui m’a simplement dit « prends une pause ». Et j’ai pris une pause.
Je sais qu’il est difficile d’appréhender les signes d’un burn-out. On se dit toujours que ce n’est qu’une passade… Mais couper quelques semaines m’a permis de remettre un peu les pieds sur terre et surtout me redonner des certitudes. Le plus beau, c’est que toute l’équipe, comme d’habitude, a fait preuve d’une solidarité et d’un soutien sans faille. Merci pour ça, je suis toujours aussi chanceux de bosser avec vous <3
Chaque cas est différent et le burn-out est un sujet sensible, mon seul conseil sera de faire preuve d’humilité. Parlez-en c’est déjà beaucoup. Si vous ne changez rien, rien ne changera.
Et maintenant ?
C’est mieux. On élimine toute prise de décision basée sur l’émotionnel. On mesure tout, on essaie d’arriver avec des arguments et on se dit tout. On a d’ailleurs mis en place la rétrospective de Comité de Pilotage ! Expérience intéressante, on applique les rituels agiles aux membres du Copil, pas forcément habitués à ce genre de choses. Globalement, quand on se rend compte que des échanges ne sont pas assez fréquents, honnêtes ou naturels, je trouve que les ritualiser est une bonne chose. Les retours sont bons et les relations assainies.
Cet article a été le plus dur à écrire de la série. Je crois aussi que c’est le plus important. La vie en startup n’est pas un long fleuve tranquille basé sur le succès et les millions qui coulent à flot.
Cela fait plusieurs mois que nous avons mis en place un nouveau rituel avec l’équipe : le Mob Code Review et il est temps d’en donner un petit feedback. Comme toujours dans le développement, cet article est à nuancer avec votre propre contexte d’équipe. Prenons juste le temps d’expliquer les pour et les contre d’une méthodologie qui a changé nos journées.
Définition
On connait le Mob Programming… Le Mob Code Review, est basé sur le même principe : faire la code review en équipe, au même moment, sur un sujet donné.
Retour en arrière…
Déjà, un peu de contexte. Karnott, c’est une équipe produit de moins de 10 personnes, avec beaucoup de compétences différentes. Système embarqué, Gestion de base de données, de l’infra, du soft backend, du front, du mobile… Et pour faire tourner tout ça, une multitude de langages différents (citons Golang, Java, Kotlin, C, Rust, SQL, Javascript, Bash…), et ne parlons même pas des frameworks utilisés dans chaque brique technique. Le choix du langage n’a jamais été un sujet chez nous, on fait au mieux avec ce qu’on maitrise et la problématique à traiter, Jusqu’au jour où cette variété de compétences est devenue un frein à notre vélocité.
Pourquoi cette perte de vélocité ? Il y a bien longtemps qu’on avait identifié le Bus Factor : laisser quelqu’un dans son coin avec ses compétences et ses connaissances fonctionnelles était inacceptable. L’une des manières de forcer le partage de connaissance, c’est de passer par la case code review. (En plus des divers avantages liés à la qualité de code, bien entendu).
Un Kanban des plus classiques
Malheureusement, les tâches avaient tendance à s’accumuler en To Review. Nous en avons parlé et avons identifié deux raisons principales :
Faire de la review, c’est prendre le temps de le faire. Je suis sûr que tout le monde a eu ce souci à un moment ou à un autre : il faut s’interrompre dans sa propre tâche, se plonger dans une autre, en comprendre la complexité, etc. Bref, faire de la review, c’est une vraie tâche en soit, et ce n’est pas si simple de savoir quand le faire.
On ne se sent pas toujours pertinent à faire la review. Trop éloigné de son domaine de compétence, technique ou fonctionnelle…
Premier test : à la suite du daily
Quand une solution s’offre à nous, et qu’elle nous parait pertinente, nous l’intégrons aux rituels d’équipe pour ne pas être tenté de le squizzer. Il faut vraiment jouer le jeu. Nous nous sommes mis d’accord sur un daily à 9h30, qui permet d’identifier les tâches à review, suivi d’une review collective et systématique.
Avantages : – On a découvert le Mob Code Review tous ensemble – Aucune tâche ne pouvait plus être laissée de côté – L’équipe s’est vraiment intéressée à tous les sujets, même si on sortait de notre zone de confort – Uniformisation des pratiques de développement
Inconvénients : – Si plusieurs tâches sont à review, ça peut être chronophage. – Alors qu’une partie de l’équipe se sent plus productive le matin à coder, enchainer tous les jours daily + review, la matinée était rapidement perdue.
Fonctionnement actuel
Comme toujours, on prend les feedbacks, et on itère pour améliorer les choses. On a donc déplacé la review au début d’après-midi, et on essaie d’être là, sauf impératif. Pour que tout le monde soit au courant de la nécessité d’une review, on a mis un petit rappel slack qui apparait à 11h tous les jours :
It’s a Yesss !
Déroulé
Mais comment ça se passe, une mob review ? NB : Notre équipe est en full remote depuis plusieurs mois / années maintenant (ça fait bizarre de le dire d’ailleurs). Donc premier conseil, choisissez une plateforme de streaming qui permet de partager son écran en haute def, ce qui permet la lecture de code. Exit Discord, on se retrouve sur Google Meet.
Le / la responsable du code va présenter : – Le but de sa Pull Request – Le contenu, plus ou moins détaillé – Potentiellement il y aura une démo S’en suivront un jeu de questions, de remarques, on voit si toutes les choses obligatoires y sont (documentation / tests).
Si tout est OK, la PR pourra être mergée dans la foulée. Et si ça nécessite du travail en plus et bien pas de problème, la personne retravaillera dessus quand elle le pourra.
Alors, en avez-vous besoin ?
Si vous avez une équipe avec des compétences homogènes, sur un scope fonctionnel bien délimité, je ne pense pas qu’il faille aller jusque là.
Mais si vous voulez faire monter des personnes en compétence et améliorer la communication horizontale entre les membres, c’est un très bon outil. Chez nous, il en a découlé des choses rigolotes, comme du Pair Programming entre des personnes qui n’avaient, jusque là, pas grande intéraction.
Des tâches qui ne peuvent plus rester bloquées, une équipe soudée, un partage de connaissance, bref, on valide tous. L’investissement en temps est le bon, dans notre contexte, même s’il est non négligeable. Mon conseil sera simplement d’écouter l’équipe pour arriver à trouver le bon équilibre.
L’an dernier, j’avais déjà écrit un premier article racontant mes 12 premiers mois chez Karnott. Cette année, je voulais réitérer l’expérience, histoire de faire le point sur ce qui a été accompli, nos réussites et nos échecs. J’ai beaucoup cogité, ne sachant par où commencer, et je suis tombé sur ce tweet :
L’article pointé apparait comme une évidence aujourd’hui, mais ça ne l’était pas il y a un an.
Remise dans le contexte
Juin 2018. Equipe constituée de 3 développeurs, dont moi. Nous avions commencé à prendre le virage de « la data », ce qui voulait dire être capable de la stocker, la traiter, la partager. Autant dire que les 3 sujets sont très propices à l’over-engineering. En août et septembre 2018, nous nous sommes renforcés avec 2 personnes de plus, expérimentées. Plutôt Backend et Devops, avec l’objectif de sécuriser notre plateforme.
Techniquement, où en étions-nous ? Une API redéveloppée en Golang, de l’intégration continue qui produit des JARs, du Ruby, du Go, du JS, et des scripts bash de déploiement sur des VMs plus que fragiles. Pour notre Devops, le premier chantier tombait sous le sens : rationaliser notre déploiement continu, et plus globalement, notre hébergement.
Choix technique, scalabilité et résilience…
A J+500 dans ma vie de CTO chez Karnott, Il était temps de faire l’un de ces fameux choix critique qui impacterait notre façon de travailler, mais aussi notre SRE, le cout de notre infra (et donc le modèle économique de l’entreprise), et qui restera surement plusieurs années : passer sous Kubernetes et Google Cloud Platform.
J’entends d’ici les critiques classiques : « c’est pour la hype, vous n’en n’aviez pas vraiment besoin, vous avez introduit plus de problèmes que vous en avez résolu… ». Reprenons le cahier des charges que nous nous étions fixés :
Avoir un DSL décrivant nos services et notre infrastructure (même si bon sang, le YAML…)
Uniformiser la façon dont nous déployons tous nos services
Gérer du 0 downtime pendant nos montées de version
Avoir une façon simple de monitorer et gérer la montée en charge
Ne pas avoir à se soucier de la captation de logs, et être capables d’en générer des métriques simples (ai-je des erreurs sur l’un de mes services ?)
Pouvoir profiter de services managés si besoin, et ne rien s’interdire techniquement (capacité à faire un POC rapidement dans une nouvelle techno)
Et franchement, la stack choisie a répondu à toutes nos attentes. La mise en place a été très rapide (moins d’un mois à mettre en place, avec la dockerisation de nos services), même si, avec le recul, trois éléments ont facilité la migration :
La base de données n’est pas « Kubernetisée », mais gérée à côtée.
Nous n’avons aucune problématique réseau compliquée, tous nos messages internes transitant à travers Google Cloud PubSub
La personne de l’équipe qui a mis tout ça en place, David, avait l’expérience pour le faire
La conception produit et les interrogations
D’un point de vue technique, le reste de l’année a été consacré en grande partie à l’amélioration de notre scalabilité dans la gestion de la flotte de Karnott. Cela revient à améliorer notre capacité à stocker, transformer, visualiser la donnée, mais aussi améliorer notre gestion du support pour fournir les bons outils à l’entreprise pour diagnostiquer au plus vite le moindre soucis. Ces problématiques seront toujours un fil rouge chez Karnott, et mériteraient pas mal d’articles pour parler de la vente d’objet physique à l’échelle d’une startup… (Coucou Amaury, Guillaume et Georges !)
ça commence à avoir de la gueule non ?
Et la création produit dans tout ça ?
Revenons-en au développement de l’application Karnott, que nos clients utilisent tous les jours. Lors de la première année, nous avons développé une application. Lors de cette seconde année, nous avons essayé de développer la bonne application. Mais encore ? C’est maintenant que je vous renvoie à l’article cité premier paragraphe. Nous n’insisterons jamais assez sur le fait que pour construire le bon produit, le développeur en startup doit être pragmatique, ne pas avoir peur de s’approprier le métier, et faire parfois des concessions sur la technique pour satisfaire un besoin urgent, que l’on ne comprend pas toujours, ou que nous aurions souhaité différer pour X raisons. Oui nous introduisons tous les jours de la dette et je suis persuadé qu’il est important de le faire. Finalement, nous ne faisons que caler notre modèle sur celui de la startup. Ce n’est pas de la dette, mais de l’investissement, qui nous permet d’avancer.
Mais est-ce vraiment le BON produit ?
C’est la grande question. Comment éviter la surcharge featurale ? L’empilage de fonctionnalités en espérant que cela convienne ? Cette seconde année, nous avons pris le parti de prendre un maximum d’initiatives. Concrètement, chaque développeur a travaillé main dans la main avec nos différentes équipes : Customer Success et support ( <3 ), l’équipe commerciale, l’équipe marketing, le Design, et bien entendu nos fondateurs pour garder la vision d’un produit utile et simple, profondément ancrée dans l’ADN de l’entreprise. Cela passe aussi par une réflexion UX de tous les instants. Un résultat simple implique toujours une conception compliquée.
Quelques choix forts de l’année : nous avions absolument besoin d’une présence sur les stores Android et iOs, ce qui a amené une nouvelle stack technique chez nous ( React Native). Autre exemple qui peut paraitre anecdotique, un client, ça n’aime pas le CSV. Quand on lui fait télécharger un export, c’est du format excel obligatoirement ! Nous avons aussi fait de la dataviz autour de la Geodata et expérimenté des choses rigolotes…
D3js, leaflet, de la donnée sympa, et on peut faire de belles choses !
Bilan
Le bilan de cette seconde année, c’est que nous sommes fiers du travail accompli. Maintenant pour passer un cap, et continuer à construire le bon produit avec toute la connaissance métier et client accumulée, nous savons que nous avons besoin de nous structurer différemment. Cela passe par le recrutement obligatoire d’un Product Owner / Product Manager (poste ouvert!) qui sera le pivot de l’entreprise, le carrefour entre toutes les approches clientes différentes. Mettre sur papier les persona, les obstacles et les opportunités, prioriser, analyser plus profondément les besoins et la pertinence de chacun, c’est notre limite d’aujourd’hui. Les besoins en UX sont aussi très présents. Comme je l’ai évoqué, nous attachons beaucoup d’importance à la simplicité du produit. Cela passera aussi par le recrutement d’un UX à temps plein.
J’en profite pour mettre un petit lien vers notre page WelcomeToTheJungle, cette page donne un bon aperçu de nos différents corps de métier, et de la bonne humeur générale 🙂
Un dernier mot pour les développeurs qui auront travaillé chez Karnott cette année. François, Georges, David, Guillaume, Paul et Amaury. Développeur en startup, ce n’est pas jouer au ping pong et rigoler toute la journée… Cette année, il y avait de la solidarité, de l’envie, de la compétence et c’était vraiment chouette. Merci à eux.
Cela fait dix ans que je fais de la prestation de service en informatique. Dix ans que je fais du forfait, de la régie, des réponses à appel d’offre, que je rencontre des clients avec des besoins divers et variés.
En dix ans, j’aurais cotoyé le monde pharmaceutique, l’industrie aéronautique, automobile, le monde bancaire, l’univers de la grande distribution, associatif, de la startup au grand groupe, de Bâle à Lille en passant par Toulouse ou Paris. Cette variété de métiers et de façon de faire du développement est l’une des raisons qui m’avait poussé en sortant d’école, à entrer dans le monde du service et des mal-aimées « SSII ».
Alors, 10 ans plus tard, est-ce que j’ai vraiment appris des choses ?
Déjà, j’aurais appris à aimer mon métier. J’ai eu la chance de croiser des développeurs passionnés, et il est clair que c’est contagieux! Merci aux JUGs de Toulouse, Paris ou Lille, aux GDGs de France, et à l’ensemble des Sfeiriens qui ont tous été plus qu’inspirants.
Mais la principale leçon de ces 10 ans, c’est que la technique n’est qu’une petite composante d’un projet informatique. Prenons le métier, l’humain, les compétences à disposition, le temps disponible, la conjoncture, la pleine lune ou la météo, mettons tout ça dans un panier, et on en sort les vrais défis à surmonter. La technique est une composante essentielle, mais non suffisante.
Si je parlais à mon moi d’il y a 10 ans, lui conseillerais-je de faire du service ?
Sans hésiter.
Je ne sais pas si j’aurais été meilleur développeur autrement, mais je suis heureux de ne pas avoir été enfermé dans ma bulle, et heureux de toutes ces rencontres.
Et maintenant alors ?
Et maintenant, le grand changement. J’ai décidé de rejoindre le 1er juin l’équipe de Karnott en tant que CTO. Un terme pompeux pour un challenge bien réel. Le projet est chouette, l’un des deux fondateurs est agriculteur et connait parfaitement son métier (chouette, un nouveau domaine fonctionnel!). Plusieurs choses me plaisent dans ce challenge :
– Chaque pierre posée le sera pour mon employeur direct. La SSII a ce côté frustrant de n’être toujours que de passage…
– Je ne pourrai pas être plus proche de l’utilisateur final! C’est quelque chose que j’avais souvent reproché à mes différents projets par le passé…
– L’un de mes objectifs est de fonder une équipe technique complète. Rassembler des personnes compétentes qui partagent les mêmes valeurs que moi, j’y ai participé avec Sfeir Lille, et humainement c’est génial. (D’ailleurs, si vous êtes dans le Nord, que vous en avez marre du retail et que vous voulez faire de l’IOT, on recrute 😉 ) – Techniquement, il y a carte blanche. Et comme on vit une époque formidable, je crois qu’il y a de quoi bien s’amuser.
– Pas un jour qui passe sans qu’on entende parler de startup. Je crois qu’il ne faut pas mourir idiot et vivre ça de l’intérieur au moins une fois…
Bref, c’est stressant, angoissant, et encore un saut dans l’inconnu… Mais après tout, qu’est ce qu’on risque ?
