Post de Sébastien ROUECHE

Le développeur est un créateur de valeur ! Pour créer de la valeur, il faut maîtriser le produit et ses évolutions futures.

Voir une entreprise grandir de l’intérieur, c’est un vrai défi… et une grande fierté 😎 Cela fait maintenant plusieurs années que je travaille avec Melchior. Au fil du temps, j’ai vu cette entreprise évoluer, ses besoins se transformer, et son infrastructure nécessiter de plus en plus d’adaptations. En tant que Lead Developer, mon rôle ne se limite pas à appliquer un cahier des charges et à écrire du code, mais à accompagner la croissance de mes clients en pensant et en adaptant les outils et les processus tout au long de la vie de l’entreprise. Récemment, avec Julien Delavisse ♾️☸️🐍, nous nous sommes concentrés sur l’optimisation du processus de développement et de déploiement. L’objectif pour les clients : rendre le site plus stable, plus rapide et réactif afin d’anticiper la montée en puissance du flux. L’objectif pour nous : gagner du temps, optimiser nos processus et sécuriser davantage l’environnement de développement. 💡 Pourquoi c’est important pour une entreprise ? Parce qu’un développeur ne fait pas que “créer un site” : il s’assure que les outils évoluent avec vous, que le système reste fluide même quand l’activité grandit, et que chaque membre de l’équipe puisse se concentrer sur ce qui compte vraiment 😁. Merci à Cécile Taillard, Emmanuel Chassaing et toute leur équipe pour la confiance accordée 🙏🏻 (et une pensée pour Raphaël Marchant avec qui j’ai (beaucoup) échangé durant toutes ces années). #DéveloppementWeb #Optimisation #Processus #Adaptabilité #VieDEntreprise

"La roadmap à trois mois ? Je ne sais pas, demande au PO !" "Je ne sais pas pourquoi on doit développer ce ticket, il est priorisé dans le backlog" Trop souvent les développeurs se "cachent" derrière les décisions des profils fonctionnels, et se mettent en situation de simples exécutants. Je trouve ça d'une tristesse absolue : développeur c'est un métier fondamentalement créatif. On le choisit car on aime créer des solutions grâce à la technologie, pour résoudre des problèmes et aider les autres. Dans certains cas, ils ont peu de marge de manoeuvre. La taylorisation des activités IT les relègue au rang de seconds, voire de troisièmes couteaux. Mais ça n'est pas le cas partout et pléthore d'équipes construisent des applis différemment : 👉 avec des pizza-teams pluridisciplinaires : UX, POs, devs et OPS 👉 sur des cycles courts pour impacter le business fréquemment 👉 en forte proximité avec les utilisateurs et les sponsors : pour faire les bons choix Et dans ce type de contexte, les fonctionnels ne sont ni plus intelligents ni plus importants que les techs. La réussite des projets dépend d'un équilibre entre les deux visions. Et les tech connaissent les plateformes sur lesquelles ils bossent : ⚡ Les composants complexes et sans harnais de tests automatisés, les nids à bugs ⚡ Les choix techniques sur lesquels ils se cassent les dents et qui les ralentissent ⚡ Les opportunités d'amélioration qui boosteraient leur productivté ⚡ Les éventuelles failles de sécurité ou problèmes de perf Ils sont donc aussi bien placés que les autres pour prendre part aux décisions stratégiques . Mais encore faut il la prendre, cette place. Et c'est là que le bas blesse: beaucoup de devs ont tendances à se mettre naturellement dans la roue des POs et les laisser prendre les décisions structurantes, plutôt que de les prendre avec eux. Plusieurs raisons : 1️⃣ Culturelles : on paie le poids historique du modèle MOA / MOE Français 2️⃣ Sociologiques : le quotidien du développeur ne l'arme pas bien à défendre des arguments qui percolent auprès d'un client 3️⃣ Par facilité : il y a un côté confortable à rester dans sa zone de confort 4️⃣ Par peur : de donner son avis, d'être illégitime, de quitter "la tech"... Alors, développeurs : prenez (en partie) le pouvoir. Ca sera bénéfique : 🔥 pour vos projets : des solutions plus pragmatiques, moins de dette 🔥 pour les profils fonctionnels avec qui vous travaillez : ils seront plus forts en face des clients avec des devs à leurs côté pour défendre des choix 🔥 pour vous : de nouvelles compétences et la compréhension d'enjeux qui dépassent le dev Comment commencer ? 👉 Faites des "vie ma vie" avec vos POs, vos UX 👉 Participez à l'établissement du backlog pour les 3 prochains mois, avec votre PO 👉 Prenez du lead sur des activités autres que du dev : rétrospectives, grooming, animation de réunion clients... Sortez de votre zone de confort, redonnez ses lettes de noblesse à la tech ! #dev #agile #po OCTO Technology

les devs!! a lire et relire avec attention. vous vous souvenez de ce que je vous disais à propos de votre position d équipage navigant dans le système de création de technologie??? ne laissez pas le système vous transformer en... sauterelles!!!!

Quelle est la première chose à faire quand on commence un projet ? La réponse pourrait vous surprendre ! ❌ Faire toute la conception de la base de données ? Non ❌ Avoir un digramme de classes bien aux petits oignons ? Oh que non ! 🤩 La première chose à faire c'est simplement mettre en production "Hello world" le plus rapidement possible (durant la première semaine). Cela peut sembler contre-intuitif, mais cette approche a plusieurs avantages. D'abord, cela force l’équipe à se concentrer sur l’essentiel. Plutôt que de s’enliser dans des détails, on se focalise sur les fonctionnalités de base et leur mise en place rapide. Ensuite, cela permet d’obtenir des retours concrets dès le début. Cela signifie que les utilisateurs peuvent commencer à tester et à donner leur avis. Ces retours permettent d'ajuster le produit en fonction des besoins réels. Cela permet aussi de tester et de valider l’environnement de production. Vous identifiez ainsi rapidement les problèmes potentiels liés au déploiement, à la configuration ou à l’infrastructure. Enfin, cela donne un coup de boost à toute l’équipe. Voir le projet prendre forme rapidement est extrêmement motivant et renforce la cohésion autour d’un objectif commun. Pourquoi attendre des mois avant de mettre en production ? Visez une mise en prod rapide pour un démarrage efficace et centré sur l’essentiel. En fin de compte, c'est une approche qui permet de réduire les risques, d’accélérer les itérations et de maximiser les chances de succès.

💻 On code, mais surtout on décode ! Vous avez peur de parler “digital” avec un développeur ? 🚨 Que ça vire au techno-blabla incompréhensible ? 🚨 De finir avec une solution qui ne répond pas vraiment à vos besoins ? Chez DevByStep, on a compris une chose : vous n’avez pas besoin de parler technique pour parler projet. Et ça tombe bien, car on préfère parler de vous : ✅ Vos besoins. ✅ Vos objectifs clients. ✅ Vos résultats business. Notre force, c’est de simplifier : pas de jargon, que des solutions concrètes et utiles. C’est pourquoi on vous offre un audit gratuit. 👇 Un moment d’échange pour : • Identifier ce qui freine votre productivité ou celle de vos équipes. • Repérer des pistes d’amélioration simples (et parfois inattendues !). • Poser toutes vos questions, même celles que vous n’osez pas demander. Aucun engagement. Juste un coup de pouce. Parce qu’on ne “vend” pas du code 👉 On construit des solutions qui ont du sens pour vous.

Négliger la qualité de son code ou comment MAL investir dès le départ dans ses actifs techniques… Je constate tous les jours que de nombreux entrepreneurs font toujours l’erreur de négliger la qualité du code (pour de bonnes et de mauvaises raisons) de leurs actifs techniques. Voila ce qui va se passer : ❌ Prédictibilité : imaginez un projet où vous n’avez absolument aucune idée du temps que va prendre telle ou telle tâche ❌ Vélocité : au lieu de créer de la valeur, vos développeurs sont perdus dans un labyrinthe de bugs. ❌ Visibilité : sur votre board Kanban, impossible de voir avancer les user stories. Tout est bloqué ou prend 3 plombes. Frustrant ! ❌ Régularité : adieu les livraisons régulières. La roadmap devient un vœu pieux. Mauvais pour le moral des troupes ❌ Stabilité financière ? Impossible de budgéter ou prévoir des investissements sans savoir le coût réel du développement. A l’inverse si vous ne faites aucun compromis sur la qualité depuis le début : ✅ Coûts réduits : Moins de temps passé à debugger = plus de valeur ajoutée au même coût. L'équation est simple ✅ Clients satisfaits : Un bon code = moins de bugs = meilleure expérience client. On garde nos utilisateurs plus longtemps ✅ Sécurité : Des bugs = des failles. Un bon code les réduit et facilite la mise à jour. Dormir tranquille. ✅ Équipes épanouies : Développer dans de bonnes conditions rend les développeurs plus épanouis…et ça n’a pas de prix 😊 💡 La qualité du code n'est pas un coût, mais un INVESTISSEMENT stratégique : chaque euro dépensé vous revient décuplé

« Que se passe-t-il régulièrement sur un projet 2 ans après son lancement ? » On pourrait penser que les choses restent stables, mais la réalité est souvent bien différente. Après 2 ans, le projet, et notamment le code, ont traversé beaucoup de transformations. Des fonctionnalités ont été ajoutées, modifiées ou encore supprimées. Le code initial, si propre et bien structuré, commence à montrer des (gros) signes de fatigue. Les effets des mauvais choix, fait consciemment ou non, se font de plus en plus ressentir. La fameuse dette technique s’accumule. Chaque raccourci pris pour livrer plus vite finit par devenir un obstacle. Les petites imperfections ignorées au début deviennent des problèmes majeurs plus le temps passe. En réalité, le code devient de plus en plus difficile à comprendre et à maintenir. Les bugs surgissent plus fréquemment, les nouvelles fonctionnalités prennent plus de temps à être implémenter. De plus, les développeurs qui ont écrit le code initial ne sont peut-être plus là. Les nouveaux venus doivent naviguer dans une jungle qu’ils n’ont pas écrit et dont ils ne connaissent pas l’histoire. Si rien n'est fait dès le début ou rapidement après le lancement, dans 100% des cas il se passe la chose suivante : devoir tout refaire ! Comment éviter cela ? Investir dans l'excellence technique.

L’agilité en grand groupe : « On va commencer par un MVP, on est agile ! » 9 mois plus tard …. « MVP livré les gars bien joué, le client est content ! » [Enfin, on l’a FORCÉ à être content] « Et maintenant ? » « Maintenant on le passe en TMA et vous dégagez ☝️ » « Et la suite ? C’est pas maintenant que le produit prend du sens et demande des itérations ? » « Ne vous inquiétez pas on gère ça, l’équipe TMA s’en chargera ». « Mais ils ont le niveau de mon arrière grand-mère » « L’informatique est un moyen, pas une fin en soi n’oubliez pas ! » [Va pas me faire chier celui-là] En grand groupe, après le MVP c’est fini ! :) Même pas le temps de constater les impacts de l’infâme Legacy créé. Les devs sont souvent jugés géniaux alors que c’est la cata dans le code source en réalité. Pauvres clients ; et ça se met en costume devant eux. Vaut mieux mettre un pyjama, pipi et au lit. #grave #agilité #vérité #entreprise

📚 L'avantage d'intégrer les développeurs dans le support applicatifs🤝 Pour répondre à l'ensemble des besoins d'un applicatif, et bien que la tendance aille vers la spécialisation des domaines, je vois 𝘂𝗻 𝗮𝘃𝗮𝗻𝘁𝗮𝗴𝗲 𝗶𝗻𝗱𝗲́𝗻𝗶𝗮𝗯𝗹𝗲 à la centralisation des sujets auprès des développeurs. Oui, je fais ce métier car j'aime développer, mais aussi car j'aime aider les utilisateurs. Avoir des développeurs dans le bon état d'esprit qui gèrent le support permet d'obtenir une rapidité d'analyse et de correction inégalée. Peut-être qu'une demande qui revient 23 fois peut être définitivement réglée par un petit développement ? Peut-être qu'une demande anodine, se corrigeant facilement, n'est que l'effet de bord d'un plus gros problème ? Peut-être que la configuration est obscur, flou et qu'un changement de nom faciliterait en amont les choses? Les développeurs sont des personnes pleines d'idées et sont souvent confrontés aux mêmes problématique de fond. Et vous comment est géré le support dans vos entreprises?