Témoignages ⭐


Votre Ă©quipe de dĂ©veloppeur a la capacitĂ© de s'organiser mieux, mais n'y arrive pas seul. Parce que trop la tĂȘte dans le guidon, et donc pas le temps de prendre le temps ? Vous avez des projets anciens sous python, avec une dette technique Ă©norme (vieux paradigmes, branches de projet mortes mais difficile Ă  dĂ©simbriquer du code utile, manque de dĂ©couplage entre le mĂ©tier, les interfaces, le stockage ...) ? RĂ©mi, c'est clairement la personne qui peut aider une petite Ă©quipe Ă  se structurer, il a une facilitĂ© dĂ©concertante Ă  plonger dans du code qu'il ne connaĂźt pas, Ă  le corriger, Ă  l'amĂ©liorer, Ă  former les Ă©quipes pour ne plus retomber dans les mĂȘmes piĂšges. Il cherche les solutions qui s'adaptent le mieux au fonctionnement de l'Ă©quipe. C'est un vĂ©ritable atout Ă  avoir dans l'Ă©quipe, sans parler de sa bienveillance, de sa bonne humeur et de sa capacitĂ© Ă  bosser Ă  100% en tĂ©lĂ©travail et Ă  s'adapter aux collĂšgues en dĂ©calage horaire.

En tant que CEO et fondateur du projet Opquast, j’ai fait appel Ă  RĂ©mi Huguet pendant la quasi totalitĂ© de l’annĂ©e 2020. La situation technique de la sociĂ©tĂ© avant la mission de RĂ©mi Ă©tait la suivante : - une dette technique importante, - un code legacy trĂšs lourd et peu Ă©volutif, - une Ă©quipe technique trĂšs investie mais qui subissait plus qu’elle n’accueillait les demandes d’évolutions et de fonctionnalitĂ©s - une architecture de services complexe - Une scalabilitĂ© insuffisante - Des temps de dĂ©veloppements longs - Des applications trop fragiles Je n’ai pas de honte Ă  prĂ©senter un tel tableau, car je sais qu’il est trĂšs frĂ©quent, voire une peu normal dans les entreprises du secteur. Cela dit, rester dans un Ă©tat de ce type n’est toutefois pas possible si l’on veut se dĂ©velopper, amĂ©liorer son agilitĂ©, travailler plus vite, accueillir plus de clients, faire en sorte que les Ă©quipes de dĂ©veloppements soient heureuses de travailler et informĂ©es des meilleurs pratiques et de l’état de l’Art. Connaissant RĂ©mi depuis plusieurs annĂ©es et je lui ai demandĂ© de s’attaquer de front Ă  tous ces sujets. Pendant tout l’annĂ©e 2020, RĂ©mi a travaillĂ© avec les Ă©quipes de dĂ©veloppeurs et avec le reste des Ă©quipes. Il a alternĂ© des chantiers de fond et des interventions beaucoup plus rapides. Il a organisĂ© des ateliers auprĂšs des dĂ©veloppeurs et changĂ© en profondeur Ă  la fois les modes de travail, l’architecture, et les choix technologiques de l’entreprise. De mon cĂŽtĂ©, j’ai Ă©galement Ă©tĂ© amenĂ© Ă  faire des choix majeurs, mais je crois pouvoir dire que ni moi ni mes Ă©quipes n’ont Ă©tĂ© brusquĂ©es ou contraintes lors de cette pĂ©riode. RĂ©mi a fait preuve d’une Ă©coute et d’une capacitĂ© d’adaptation hors du commun, pouvant passer avec aisance d’un chantier stratĂ©giques Ă  un chantier de traitement de bugs urgent pour supplĂ©er l’équipe en cas de besoin. Bref, RĂ©mi est une ressource trĂšs prĂ©cieuse, avec une excellente capacitĂ© d’écoute et d’adaptation. Son intervention auprĂšs d’une Ă©quipe est au minimum utile et au moins en ce qui concerne Opquast, a Ă©tĂ© extrĂȘmement rentable. Ce tableau dithyrambique n’aurait de valeur que s’il mentionnait Ă©galement des faiblesses: j’en citerai deux, une petite tendance Ă  abuser des gifs et son revers au tennis de table.

J'ai eu l'occasion de travailler avec RĂ©mi pendant un an et sous son impulsion je n'ai jamais autant progressĂ© et en aussi peu de temps. Avec lui, j'ai eu le sentiment d'ĂȘtre Ă  la pointe de ce qui se fait, tant dans le domaine de la conception que dans l'utilisation des derniĂšres technologies. Il a cette grande qualitĂ© d'ĂȘtre sensible Ă  vos arguments et recommandations. Ce qui est important pour RĂ©mi c'est le produit pas l'Ă©go des dĂ©veloppeurs. J'ai vraiment apprĂ©ciĂ© de travailler avec RĂ©mi.

PersuadĂ©e du bien fondĂ© des tests fonctionnels et de l’approche TDD depuis bien des annĂ©es, l’équipe technique, impuissante, n’arrivait jamais Ă  passer l’étape de la mise en place pour la raison principale: mĂ©thodologie ! Quoi tester ? Comment le tester ? Jusqu’à quel niveau ? Le mur semblait infranchissable, aucune vĂ©rification ne semblait possible sans faire appel Ă  la base de donnĂ©es et un jeu de test consĂ©quent, une frustration permanente, l’enfer. (Notre application a 11 ans). Depuis bien des annĂ©es en bon Ă©tudiant et bon soldat nous avons suivis deux voies pĂ©rilleuses, celle de la mĂ©thode Merise et l’acceptation de l’ORM comme pierre angulaire de tout bon projet Web. C’est rassurant mais il y a des limites. Il y a des rencontres que l’on sait importantes, que l’on espĂšre parfois, et que l’on bĂ©nit d’ĂȘtre arrivĂ©e. Celle de RĂ©mi est salvatrice Ă  bien des Ă©gards. La rencontre de RĂ©mi fait partie d’une Ă©tape importante, qui, non contente d’avoir amĂ©liorĂ© mes propres pratiques de dĂ©veloppement, a trĂšs largement consolidĂ© la qualitĂ© de production et la rĂ©silience de l’équipe technique Opquast. RĂ©mi, dotĂ© d’une incroyable bienveillance, a la capacitĂ© rare de comprendre immĂ©diatement votre projet, votre module, votre code, d’en tirer ses faiblesses, d’entrevoir les axes d’amĂ©liorations. RĂ©mi vous accompagne et vous emmĂšne Ă  revoir vos schĂ©mas de pensĂ©e, vous invite Ă  vous poser les bonnes questions pour rĂ©pondre aux besoins fonctionnels de vos utilisateurs. Cela paraĂźt Ă©vidant dit comme cela, mais le prisme technique nous absorbe trĂšs souvent. RĂ©mi maitrise la technique, Django chez nous , les concepts, une grande partie des designs patterns mais son expĂ©rience professionnelle lui permet de proposer un accompagnement et des formations toujours Ă©clairĂ©es jamais dogmatiques, un vrai bonheur. Je pense que vous l’avez compris, telle une reine dans un jeu d’échec, RĂ©mi est une ressource de qualitĂ© pour faire grandir vos Ă©quipes techniques. PS : Par manque d’humour il prĂ©fĂšre communiquer par gif, parfois de plusieurs mĂ©ga octets, bref l’écologie n’est pas son domaine.