Je conçois votre architecture, et je rends ses règles vérifiables par la machine.

Un développeur exécute une décision ; un architecte prend celle dont les autres dépendent. Vous avez besoin d’un architecte quand un choix de structure engage les mois qui suivent — quelles frontières, quelles données, quelles dépendances, et qui répond de quoi. Le coût d’une architecture mal posée se paie plus tard, en réécritures, en incidents et en fonctionnalités devenues impossibles à ajouter, souvent quand plus personne ne se souvient du choix d’origine. Ce qui se discute avec moi, c’est ce qu’il y a à faire et dans quel ordre. Si vous hésitez, la séance d’une heure vous donne de quoi trancher.

Vous gardez la main sur votre code. Pour la séance d’une heure, c’est vous qui lancez un programme de lecture sur votre machine. Il lit la structure du projet, ses dépendances, ses fichiers de configuration et l’historique des modifications. Il ne modifie pas votre code, il n’effectue aucun appel réseau, et sa sortie s’affiche chez vous : vous la lisez avant moi. Pour l’audit de trois jours, un accès en lecture à votre dépôt rend le travail nettement plus fin ; il reste possible de travailler sur un export que vous préparez, et un accord de confidentialité signé avant la première minute ne me pose aucune difficulté. Cette réticence est plutôt bon signe : un dirigeant qui hésite à ouvrir son code à un inconnu a déjà compris quelque chose.

Oui, c’est mon mode de travail habituel. L’architecture se décide par écrit : un document qu’on relit, une règle qu’une machine vérifie, une décision datée avec son motif. Ces objets survivent à la réunion qui les a produits. Une décision prise à l’oral, entre gens d’accord sur le moment, ne laisse rien à celui qui arrive six mois plus tard. Je travaille depuis Montpellier, pour des clients qui sont ailleurs, et je me déplace en France pour un atelier de cadrage ou une présentation de conclusions quand la réunion le justifie — décompté en jours de mission, sans supplément déguisé.

Oui. Ce qui se transporte d’un langage à l’autre, ce sont les séparations : quelles règles votre système doit garantir, où elles sont vérifiées, et ce qui se passe quand quelqu’un les franchit. Ce raisonnement vaut en Python, en Go, en PHP ou en Ruby, et j’ai déjà travaillé sur d’autres langages que les miens. Mon expertise la plus forte est sur Node.js et TypeScript : c’est là que je m’engage sans réserve, et sur un audit dans un autre écosystème, je distingue dans le rapport ce que je lis avec certitude de ce que je lis avec réserve. Pour une mission au long cours sur une autre technologie, le bon montage est avec un relais dans votre équipe qui la pratique au quotidien — et je préfère vous le dire maintenant.