Romain Texier

L'entreprise

Leadformance est la filiale grenobloise de Solocal, installée à Montbonnot-Saint-Martin. Elle édite BRIDGE, une plateforme de gestion de données locales et de store locator utilisée par plus de 220 enseignes à réseau physique dans le monde : chaque point de vente y gère sa page, ses horaires et sa visibilité locale.

Le contexte

Un produit de présence en ligne servi à un large portefeuille de clients, à faire évoluer sans casser l'existant.

Ce que j'ai fait

Conception et développement des interfaces en Angular, livrées en continu via une chaîne GitLab / Jenkins / SonarQube et déployées sur Kubernetes.

Mon rôle

Développeur web front-end, au sein d'une squad Agile Scrum de dix personnes.

Ce que j'ai fait concrètement

• Conception et développement d'interfaces Angular pour les écrans de gestion des points de vente.
• Travail à partir des maquettes, en allant discuter les cas limites avec les designers plutôt que de les intégrer tels quels.
• Revues de code et rituels Scrum : daily, refinement, rétro, sur des tickets suivis jusqu'à la mise en production.
• Chaîne d'intégration continue GitLab / Jenkins / SonarQube, images Docker déployées sur Kubernetes.
• Services applicatifs sur AWS, stockage des médias sur S3.

Stack

• Angular
• NestJS
• Kubernetes
• AWS

L'entreprise

Sourceamax est une société d'ingénierie logicielle spécialisée dans les applications métier à forte valeur ajoutée, présente en France, en Australie et au Cambodge. Elle fait partie du groupe Axiv IT, premier pôle d'expertise Adobe ColdFusion en France et partenaire d'Adobe de longue date — d'où un existant ColdFusion important à faire évoluer.

Le contexte

Des écrans métier vieillissants, adossés à un backend ColdFusion difficile à faire évoluer.

Ce que j'ai fait

Refonte complète des interfaces en VueJS et reprise du backend sous forme d'API REST, à trois, du cadrage à la mise en production.

Mon rôle

Développeur web full stack, dans une équipe de trois, du cadrage à la mise en production.

Ce que j'ai fait concrètement

• Refonte complète des interfaces métier en VueJS, écran par écran, sans interruption de service.
• Reprise du backend ColdFusion existant sous forme d'API REST, pour découpler l'affichage des données.
• Reprise des parcours utilisateur au passage : formulaires allégés, états de chargement et d'erreur explicites.
• Équipe resserrée : peu de couches entre la demande métier et la livraison.

Stack

• VueJS
• REST API
• ColdFusion

L'entreprise

L'Échiquier Grenoblois est un club fondé en 1962, qui compte environ 220 licenciés. Chaque saison, il engage des équipes de 8 en Interclubs (de la Nationale 2 à la Nationale 4) et des équipes de 4 au niveau régional. En 2022, le club a terminé 3e des finales nationales.

Le contexte

Composer les équipes avant chaque ronde : ordre des échiquiers, quota de joueurs mutés, compteur de participations sur la saison, absents du week-end. Tout satisfaire en même temps est rarement possible.

Ce que j'ai fait

Un outil en NuxtJs qui cherche la composition satisfaisant le plus de contraintes possible, en propose plusieurs classées, et affiche noir sur blanc celles qu'il a dû relâcher.

Mon rôle

Développeur web full stack, en Agile Scrum dans une équipe de 7 personnes.

Ce que j'ai fait concrètement

• Moteur de composition qui maximise le nombre de contraintes respectées, au lieu d'échouer dès qu'une seule bloque.
• Contraintes tirées du règlement FFE : échiquiers dans l'ordre des Elo décroissants, trois joueurs mutés maximum par match, onze participations maximum par joueur sur l'ensemble des Nationales.
• Elo retenu selon la hiérarchie du règlement — dernier Elo FIDE, à défaut Elo national, à défaut Elo estimé.
• Plusieurs compositions proposées et classées, pour laisser le capitaine trancher avec ce qu'il sait du terrain.
• Les contraintes relâchées sont affichées explicitement : l'outil ne cache jamais un compromis, et un brûlage dépassé coûte l'échiquier par forfait.
• Feuille de composition prête dans l'ordre des échiquiers, à remettre à l'arbitre un quart d'heure avant la ronde. Développement en NuxtJs, déploiement sur Ionos.

Stack

• NuxtJs
• Ionos

L'entreprise

Projet personnel, né d'un constat en atelier : le temps passé à relire des notes d'entretien est du temps qu'on ne passe pas à concevoir.

Le contexte

Des heures de notes d'entretien utilisateur à dépouiller avant de pouvoir formuler le moindre persona.

Ce que j'ai fait

Un outil qui envoie les notes brutes à un modèle de langage, en extrait les motifs récurrents et propose des personas et un parcours utilisateur à retravailler. L'IA débroussaille, le designer décide.

Mon rôle

Conception et développement, de bout en bout.

Ce que j'ai fait concrètement

• Import des notes brutes d'entretien, sans mise en forme préalable.
• Appel à un modèle de langage pour extraire les motifs récurrents : objectifs, freins, verbatims.
• Proposition de personas et d'un parcours utilisateur, présentés comme un brouillon à corriger, jamais comme un résultat.
• Chaque affirmation reste reliée aux extraits de notes qui l'ont produite, pour pouvoir la vérifier.

Stack

• SvelteKit
• TypeScript
• Claude API
• Figma

L'entreprise

Exercice de refonte personnel, sur un usage que je connais : rejoindre une station un samedi matin, à plusieurs, sans y passer la matinée.

Le contexte

Réserver un trajet vers une station un samedi matin demande trop d'étapes, sur un écran qu'on consulte souvent gant à la main.

Ce que j'ai fait

Parcours repensé en trois écrans : wireframes, design system et prototype cliquable sous Figma. Cibles tactiles élargies et contrastes renforcés pour un usage en extérieur.

Mon rôle

Recherche, conception d'interface et prototypage.

Ce que j'ai fait concrètement

• Parcours existant décortiqué écran par écran pour repérer les étapes qui n'apportent rien.
• Réservation ramenée à trois écrans : où, quand, avec qui.
• Cibles tactiles élargies et contrastes renforcés — l'écran se consulte dehors, souvent avec des gants.
• Design system et prototype cliquable sous Figma, pour tester le parcours avant d'écrire une ligne de code.

Stack

• Figma
• Design system
• Prototypage
• Tests utilisateurs

L'entreprise

Projet personnel parti d'une frustration : les corrections d'accessibilité arrivent presque toujours après coup, quand elles coûtent le plus cher.

Le contexte

Les problèmes d'accessibilité se découvrent trop tard, une fois l'écran déjà intégré.

Ce que j'ai fait

Un assistant qui analyse un composant, signale les écarts WCAG et propose une correction. Les règles mesurables sont vérifiées par du code ; l'IA sert à expliquer et à prioriser, pas à décider seule.

Mon rôle

Conception et développement, de bout en bout.

Ce que j'ai fait concrètement

• Analyse d'un composant et détection des écarts WCAG 2.2 : contraste, ordre de tabulation, libellés manquants.
• Les règles mesurables sont vérifiées par du code (axe-core), pas par le modèle — pas de faux positif inventé.
• Le modèle sert à expliquer l'impact réel pour l'utilisateur et à prioriser, là où une liste brute ne dit rien.
• Correction proposée sous forme de diff, à relire avant application.

Stack

• TypeScript
• Claude API
• axe-core
• WCAG 2.2