Une architecture qui tient la charge, l’équipe et le temps.

À qui s’adresse cette mission

Cet accompagnement est utile si vous êtes :

• Fondateur ou CTO qui doit poser les fondations d’un nouveau produit
• Entreprise qui lance une refonte et veut éviter de reproduire les erreurs de la V1
• Équipe qui grandit vite et dont les pratiques divergent d’un développeur à l’autre
• Organisation dont le produit doit s’ouvrir à de nouveaux canaux : mobile, machine, API partenaires

Les signaux d’alerte

Vous reconnaissez au moins un de ces symptômes :

• Chaque nouvelle fonctionnalité coûte plus cher que la précédente
• Deux développeurs résolvent le même problème de deux façons différentes
• Personne ne sait dire où doit vivre une nouvelle règle métier
• Les décisions techniques structurantes ne sont écrites nulle part
• Le front et le back se renvoient la responsabilité des mêmes bugs
• Vous devez brancher un nouveau client (mobile, machine, partenaire) et rien n’était prévu pour
• Les temps de build et de déploiement rendent l’itération pénible

Ce sont des symptômes d’architecture, pas de code. Les corriger ligne par ligne ne suffira pas.

Ce que je fais concrètement

Je travaille avec vos équipes, pas à côté d’elles. La mission suit cinq étapes.

1. 1. Comprendre le métier avant la technique

   • Ateliers avec les équipes produit et métier
   • Cartographie des parcours et des règles qui comptent vraiment
   • Identification des contraintes non négociables : réglementaire, temps réel, fonctionnement hors ligne

2. 2. Cartographier l’existant

   • Lecture du code et des schémas de données
   • Repérage des couplages et des zones à risque
   • Mesure de ce qui coûte cher : build, tests, déploiement

3. 3. Poser l’architecture cible

   • Découpage en domaines et en responsabilités
   • Choix de stack argumentés, alternatives incluses
   • Contrats d’API et stratégie de données
   • Décisions consignées dans des ADR relus avec l’équipe

4. 4. Outiller l’équipe

   • Standards frontend : component-first, hooks, gestion d’état
   • Design system ou bibliothèque de composants partagée
   • Pipeline d’intégration continue, qualité de code et revues

5. 5. Accompagner la mise en œuvre

   • Pair programming sur les premiers modules structurants
   • Revues d’architecture au fil de l’eau
   • Ajustement de la cible face au réel

Ce que vous recevez

Des documents utilisables par votre équipe, pas un rapport qui dort dans un Drive.

Tout est versionné dans votre dépôt, en français ou en anglais.

L’objectif reste le même : que l’équipe puisse continuer sans moi.

Ma façon de travailler

Ce que ça change

À la fin de la mission :

• L’équipe sait où placer une nouvelle fonctionnalité sans en débattre une demi-journée
• Les décisions structurantes sont écrites et opposables
• Les choix techniques sont alignés sur le budget et les compétences en place
• Vous pouvez recruter ou faire monter quelqu’un en compétence sans repartir de zéro

Et vous gardez la main : rien de tout cela ne dépend de ma présence.

Questions fréquentes

• Quelle différence avec l’audit de stack ?

  L’audit part de l’existant et produit un diagnostic priorisé. L’architecture part de la cible : on conçoit le système à construire ou à refondre, puis on accompagne sa mise en œuvre. Les deux missions s’enchaînent souvent.

• Combien de temps dure une mission d’architecture ?

  Le cadrage initial prend deux à quatre semaines. L’accompagnement à la mise en œuvre s’étale ensuite sur plusieurs mois à temps partiel, souvent un à deux jours par semaine.

• Travaillez-vous sur site ou à distance ?

  Les deux. Les ateliers de cadrage gagnent à se faire sur site, en Île-de-France. Le reste de la mission se déroule très bien en remote, comme aujourd’hui avec des équipes réparties sur trois pays.

• Imposez-vous une stack particulière ?

  Non. Mon terrain de prédilection est TypeScript, React, Next.js et Node, mais j’ai aussi livré en C#, Flutter, VB.NET et Symfony. Le bon choix dépend de vos contraintes et de votre équipe, pas de mes préférences.

• Intervenez-vous sur des systèmes qui pilotent du matériel ?

  Oui, c’est mon quotidien actuel : architecture d’un écosystème machine + cloud + applications, avec MQTT, gestion des états hors ligne et des modes dégradés. J’ai aussi travaillé sur des bornes et des systèmes embarqués Raspberry Pi.

• Que se passe-t-il si mon équipe n’est pas d’accord avec vos choix ?

  Tant mieux : c’est le signe qu’elle s’approprie le sujet. Les ADR existent pour rendre le désaccord explicite et documenté. Une décision imposée que personne ne comprend ne survit jamais au départ du consultant.