Conseil digital transverse · Angers, FR

L'essentiel se joue avant la première ligne de code.

J'interviens en amont des projets techniques - cadrage, architecture, arbitrages - là où un choix engage toute la trajectoire.

Vos choix d'architecture sont des décisions produit.

J'aide les équipes à les trancher tôt, pendant qu'on peut encore changer d'avis.

01

Cadrer.

Le problème juste, avant tout le reste.

Avant toute solution, je clarifie l'enjeu réel : ce que le projet doit accomplir, les contraintes qui comptent vraiment, les quelques décisions qui engagent tout le reste. Je fais remonter les hypothèses implicites - celles qu'on ne questionne pas, et qui coûtent cher trois mois plus tard. Je traduis l'intention métier en termes techniques, et l'inverse, pour que chacun décide sur la même base.

02

Arbitrer.

Choisir, c'est renoncer. Encore faut-il savoir à quoi.

Une architecture, c'est une suite d'arbitrages : vitesse contre dette, simple contre flexible, maintenant contre plus tard. Je rends ces choix explicites au lieu de les laisser se faire par défaut. Je pose les options sur la table, avec leur coût réel et leur point de non-retour. Je tranche avec vous, en assumant ce qu'on sacrifie - parce qu'un choix qu'on n'a pas nommé est un choix qu'on subira.

03

Construire.

Bâtir avec vous, pas à votre place.

Je ne livre pas une boîte noire que vous devrez ensuite déchiffrer. Je construis dans votre code, avec vos équipes, selon vos conventions - pas les miennes. À chaque étape, je transmets ce qu'il faut pour que vous puissiez continuer sans moi : les décisions, leurs raisons, ce qui reste à faire. Je réussis quand vous pouvez continuer sans moi.

Par où commencer.

Un audit, avant tout engagement.

Quelques jours pour cartographier l'enjeu, les risques d'architecture et les décisions à prendre. Un livrable clair et actionnable — et, si vous le souhaitez, la base d'une suite. Vous savez où vous en êtes avant de vous engager davantage.

Là où je fais la différence.

Onze ans à voir des architectures vieillir, des dettes se payer, des choix de départ décider de la suite. C'est ce regard que j'apporte - pas une paire de bras de plus.

Le pont entre technique et produit.

Je participe à l'élaboration des features avec l'équipe produit, pas en réception. J'apporte le point de vue technique là où il change la décision : ce qui est faisable, à quel coût, ce qu'une intention métier implique vraiment dans le code. Les deux langages, parlés des deux côtés.

La première ligne sur ce qui est difficile.

J'ouvre les chantiers structurants - refondre ce qui freine, trancher une direction d'architecture avant qu'elle ne se fige par défaut. Je porte les features les plus complexes, celles où le risque est réel. Et quand un problème bloque l'équipe, c'est vers moi qu'il remonte - la plupart du temps, il se résout.

L'exigence qui tient dans la durée.

Je choisis les dépendances sur des critères réels - maintenance, surface de vulnérabilité, poids - pas la hype. Je fais de la revue de code un moment de transmission, pas de contrôle. La qualité n'est pas une coquetterie : c'est elle qui décide de la vitesse dans deux ans.

Pourquoi Cernix.

Onze ans à construire et diriger des équipes de développement. À la fin, le même constat presque partout : les projets ne calent pas sur la technique, mais sur les désaccords d'architecture - des responsables qui défendent chacun une vision légitime, sans personne pour trancher. J'ai créé Cernix pour tenir ce rôle de l'extérieur : tracer le chemin, faire décider, structurer ce qui doit tenir au-delà des départs.

Mon terrain d'origine est JavaScript / TypeScript ; mon regard ne s'y limite pas — l'architecture ne dépend pas d'un langage. Basé à Angers, je travaille à distance comme sur site, dans l'Ouest comme à Paris.

JS / TS · Node · C# / .NET · AWS · Azure · Fullstack · Conduite d'équipe
Cadrer. Arbitrer. Construire.

Une décision en vue

Angers, FR
À distance ou sur site
Ouest & Paris