Après trois belles années chez Legalstart, au plus près de celles et ceux qui entreprennent, j’ai senti qu’il était temps de créer à mon tour. Aujourd’hui, je me lance pleinement dans cette aventure avec mon ami de toujours, Quentin Pradelle, avec notre projet Fenxi. Fenxi, c’est aujourd’hui une équipe de 4 personnes, qui grandit avec une mission simple : aider les entrepreneurs et les entreprises à créer, clarifier et améliorer leurs produits. Rendre les idées plus fortes. Rendre la technologie plus simple. Et accompagner ceux qui construisent, du premier croquis à la version qui tient vraiment la route. On avançait plutôt dans l’ombre jusqu’ici…. Et on est heureux de partager enfin ce qu’on fait et ce qu’on apprend, avec la sortie de notre blog: https://www.fenxi.fr/blog/ N'hésitez pas à nous suivre 😉 On espère que ça vous parlera autant que ça nous anime. 🐼🌱 P.S. : Et si vous lancez un projet, si vous voulez l’améliorer ou simplement en discuter autour d’un café, on serait ravis d’échanger, et on peut même vous proposer un audit gratuit, pour vous aider à avancer dans la bonne direction.

Avec les pannes d’AWS et Cloudflare, j’ai vu énormément de critiques sur le fonctionnement actuel des entreprises: “C’est irresponsable d’être dépendant d’un seul cloud.”, “Il faut arrêter de dépendre exclusivement d’AWS”, “On a recrée notre propre Cloudflare avec de l’IA” (véridique, venant d'une figure de la tech) L’idée est bonne, mais selon moi, c’est très loin de la réalité terrain : AWS, Cloudflare, GCP, OVH 🇫🇷🥖, Azure… Aucune de ces solutions n’est infaillible. La question ne devrait donc pas être : “Comment éviter 100% des pannes ?” mais plutôt “Quel niveau de risque est acceptable pour mon business ?”. Parce que derrière le fantasme du multi-cloud, il y a : → plusieurs infrastructures à maintenir → des plus grosses équipes → une complexité supplémentaire dans les déploiements ... Tout le monde en parle. Très peu peuvent se le permettre. 💸 La vraie question : combien me coûte une heure de downtime ? Avant de basculer dans une architecture plus complexe, posez deux chiffres : ❓ Combien coûte une heure / une journée d’indisponibilité ? ❓ Combien coûte une architecture conçue pour éviter ces indisponibilités ? Pour la quasi totalité des entreprises avec qui nous travaillons : 👉 le coût du multi-cloud est supérieur à l’impact business d’une panne ponctuelle. Ce n’est pas “se reposer sur ses lauriers”, c’est juste rationnel.

Comment faire pour être le vrai partenaire tech d’une entreprise, et pas un simple “exécutant” tech ? Ma vision, dans le domaine du service, c’est que faire exactement ce qu’on te demande, c’est du service trois étoiles ⭐️ ⭐️ ⭐️ (sur cinq 😉). Alors, comment, avec Fenxi, on essaye d’hausser le niveau et arriver à un service ⭐️ ⭐️ ⭐️⭐️ ⭐️ , c’est à dire qu’il est à un niveau ou le client va carrément parler de toi autour de lui ? Un client connaît parfaitement son métier. Mais il n’a pas toujours la vision produit, les réflexes UX, ou les contraintes techniques qui vont avec. Si on se contente de dire “ok, on fait comme ça”, on fait notre métier à moitié. Trois étoiles, cool. Mais notre responsabilité, c’est d’élever le niveau. Construire une solution tech, ça veut dire : → challenger ce qui n’a pas de sens → expliquer pourquoi telle idée va coûter 5x plus cher pour 2% d’impact → traduire une intention métier en un vrai produit cohérent. Un autre piège dans lequel il est facile de tomber : penser que le job s’arrête le jour de la livraison. Livrer, c’est top, mais: → est-ce que ça tient la charge ? → est-ce que les utilisateurs s’y retrouvent ? → est-ce qu’on a appris quelque chose pour la V2 ? Sinon, on fait du one-shot. Et le one-shot, ça construit rarement un produit, ni des relations long terme 🌱 Et vous, c’est quoi pour vous la différence entre un prestataire… et un vrai partenaire tech ?

La plupart des équipes démarrent un produit avec beaucoup d’enthousiasme, des bonnes idées… mais aucune garantie que quelque chose prenne vraiment. Dans notre dernier article, on essaie de répondre à une question simple : comment poser les bases d’un produit qui mérite vraiment d’être construit ? On y parle de : 💡 pourquoi l’idée n’a presque aucune valeur si le problème n’est pas clair 💡 comment distinguer solution imaginée vs problème réel utilisateur 💡 comment utiliser les Jobs-to-be-Done pour formuler un bon problème 💡 comment évaluer la valeur et les risques avant d’écrire la première ligne de code 💡 pourquoi le code doit arriver à la fin, pas au début Vu que c'est pas mal condensé (j'ai essayé de me baser sur tout les livres que j'ai préféré sur le sujet), l'article est en deux parties ... que je vous met juste en dessous 👇 Bon vendredi à tous ☀️

Les prestataires & agences qui vendent du “pixel-perfect” avant du “problem-perfect” sont dangereuses. Vraiment. 🚩 Parce que l'esthétique ne doit jamais passer avant le besoin. Le risque est triple : 1️⃣ Ça coûte trop cher. La facture grimpe avant même d’avoir créé de la valeur. 2️⃣ Chaque nouvelle feature prend plus de temps 3️⃣ On perd le focus. L’énergie part dans la cosmétique, alors qu’elle devrait être dans la résolution de problèmes concrets. Alors pourquoi certains font ça? Selon moi, la raison est simple (et un peu triste) : Ca demande moins d’énergie d’écrire du beau code… que de faire l’effort de comprendre le business d’un client 💡 Et vous, vous êtes plutôt MVP efficace ou Perfectionniste ? Dites-moi en commentaire 👇