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.

Découvrir l'audit Voir trois décisions

code ce qu'on voit, où la facture arrive
construire ce qu'on bâtit
arbitrer ce qu'on choisit, et ce qu'on sacrifie
cadrer le problème juste
faille temps de réponse divisés par trois, cas 02

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.

Trois couches, posées dans l'ordre.

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.

Le risque : Construire vite la mauvaise chose.
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.

Le risque : La dette qu'on découvre trop tard.
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.

Ce qui reste : Une équipe plus autonome qu'avant mon arrivée.

Vos équipes travaillent avec des agents IA ? La méthode est la même. Ce que ça change, et ce que ça ne change pas

Trois décisions, sur le terrain.

Pour chacune : ce qui a été retenu, ce qui a été écarté, et ce que ça a coûté.

Là où j'interviens

La dette qui ne fait plus mal mais qui ralentit tout
Les architectures qui tiennent aujourd'hui et ne passeront pas l'échelle suivante
Les migrations à risque sur du service qui ne peut pas s'arrêter
Les arbitrages garder / remplacer / construire, quand la réponse évidente est mauvaise
Les décisions techniques qui n'ont pas de propriétaire clair
Les agents IA adoptés sans savoir dire ce qu'ils ont changé

code : la situation
construire : la conséquence
arbitrer : la décision
pointillé : l'option écartée

Cas 01

Reconstruire pendant que ça tourne.

La situation. Un éditeur de logiciel métier. Le produit avait grandi par ajouts successifs, sans couche commune ni tests automatisés. Chaque nouvelle fonctionnalité coûtait plus cher que la précédente.

La conséquence. L'architecture a été adoptée, et le développeur junior de l'équipe l'a prise en main dans la foulée : une structure qu'on peut transmettre à quelqu'un qui débute est une structure qui tiendra sans son auteur.

La décision. J'ai proposé de changer de modèle : passer à une API exposée en couches, avec des tests et des règles de contribution écrites. J'ai avancé par démonstration plutôt que par argumentation.

L'option écartée. Nettoyer et optimiser l'existant : c'était la demande initiale.

Le coût accepté. Un coût immédiat contre un bénéfice que les fondateurs ne pouvaient pas encore voir. Il a fallu plusieurs semaines pour obtenir leur accord – légitimement.

Cas 02

Retirer une brique standard du chemin critique.

La situation. Une plateforme de conversation en temps réel, plusieurs milliers d'utilisateurs à l'heure. La gestion des droits reposait sur une solution du marché. Chaque appel payait un aller-retour d'autorisation externe, et les temps de réponse plafonnaient.

La conséquence. Temps de réponse divisés par trois, et une dépendance externe de moins sur le chemin critique.

La décision. Avec le CTO, nous avons retiré la brique. L'argument : notre modèle de droits était structurellement plus simple que ce que l'outil savait faire, et nous payions chaque jour une complexité qui ne servait aucun besoin réel.

L'option écartée. La réponse évidente : optimiser autour de l'existant – cache, tuning, ressources supplémentaires.

Le coût accepté. Reprendre à notre charge un composant critique et sensible, contre la règle admise qui dit de ne jamais faire ça. Un risque assumé et nommé.

Cas 03

Rendre le front accessible à toute l'équipe.

La situation. L'interface complète d'un logiciel client à refondre, avec une équipe solide dont l'expertise était ailleurs que sur le front. Les écrans revenaient toujours aux mêmes personnes.

La conséquence. L'équipe a pris le relais sur l'interface sans que je sois le passage obligé. La refonte a cessé de dépendre d'une seule personne.

La décision. Le vrai problème n'était pas l'interface, il était la répartition du travail : une refonte que seule une personne peut porter est une refonte qui ne finit pas. J'ai commencé par construire la bibliothèque de composants dont l'équipe aurait besoin.

L'option écartée. Développer les écrans directement.

Le coût accepté. Un démarrage plus lent, pour rendre la suite accessible à des développeurs dont ce n'était pas la spécialité.

Onze ans en interne, pas en missions de trois mois. J'ai vu vieillir mes propres arbitrages : ceux qui ont tenu, ceux que j'ai payés. C'est la différence entre un avis d'architecture et une décision dont on connaît le coût à trois ans.

Trois semaines pour savoir quoi décider.

Un regard extérieur senior sur les décisions techniques qui engagent votre trajectoire – celles qu'on repousse parce qu'on n'a pas le recul pour les trancher. L'audit livre les deux couches du bas : cadrer, puis arbitrer.

Ce qui se passe

Un appel de cadrage 45 min

Sans engagement. On vérifie ensemble qu'il y a bien une décision à prendre. Si ce n'est pas le cas, je vous le dis.
Deux semaines d'immersion 2 semaines

Entretiens avec vos équipes techniques et métier, lecture de votre code, revue de l'existant. Étalées, pour laisser le temps aux bonnes questions d'arriver.
Une restitution 90 min

Avec les personnes qui décident, en leur présence. C'est la condition pour que l'audit serve à quelque chose.

Ce que vous recevez

Une note de décision de 12 à 15 pages. Pas un rapport à ranger : un document sur lequel on tranche.

Votre enjeu, reformulé – le problème réel, énoncé clairement.
La carte de l'existant – ce qui tient, ce qui est fragile, ce qu'on croit à tort.
Les décisions qui engagent – trois à cinq, avec options, coût, point de non-retour et ma recommandation.
Ce qui peut attendre – explicitement.
Les 90 prochains jours – la séquence, la charge, et qui porte quoi.

Ce que ça ne fait pas

Ce n'est pas un audit de sécurité.
Ce n'est pas une revue de code exhaustive.
Ce n'est pas un plan de recrutement.
Ce n'est pas un chiffrage de projet.

Un audit qui prétend tout couvrir ne tranche rien.

Et ensuite

Si vous le souhaitez, l'audit devient la base d'un accompagnement dans la durée : je reste pour construire avec vous.

Le premier pas : un appel de cadrage de 45 minutes, sans engagement.

Réserver l'appel de cadrage

Ou par email : contact@cernix.fr. Réponse sous 24 h ouvrées.

Corentin Le Gal

Éditeur de logiciel, plateforme temps réel, applications métier. J'ai construit en interne, dans des équipes de trois à quinze personnes, toujours du côté de ceux qui livrent.

Ce que j'ai fini par constater : les projets qui dérapent ne dérapent presque jamais pour des raisons techniques. Ils dérapent parce qu'une décision structurante a été prise trop vite, par défaut, ou par personne. Le code n'est que l'endroit où la facture arrive.

Cernix est né de ce constat. J'interviens là où ces décisions se prennent, puis je reste assez longtemps pour en assumer les conséquences dans le code.

Je code toujours, chaque semaine. Ce n'est pas de la nostalgie : c'est ce qui me permet de savoir ce qu'une décision coûte réellement à ceux qui l'appliquent.

Basé à Angers. J'interviens à distance et sur site.

Une décision en vue ?

Réservez l'appel de cadrage directement dans mon agenda, ou écrivez-moi en deux lignes : le projet, la décision qui bloque.