Conseil indépendant · Product & Engineering

Vous ne savez plus exactement où est le problème.

Les délais s’allongent, les priorités bougent, les tensions montent — et chacun a son explication : l’équipe, le CTO, le produit, les process, l’architecture. J’entre dans votre organisation Produit & Engineering, je comprends ce qui s’y passe réellement et j’établis ce qui doit changer, avant de la remettre sur les rails avec vos équipes.

Le diagnostic répond à quatre questions.

  • Que se passe-t-il réellement ?
  • Pourquoi ?
  • Qu’est-ce qui doit changer ?
  • Dans quel ordre ?

Quand m’appeler

Les symptômes s’accumulent. La cause reste invisible.

Le déclencheur peut être une croissance, un client devenu prépondérant, une réorganisation, une acquisition — ou le moment où ce qui fonctionnait ne fonctionne plus.

« Je ne sais plus où est le problème. »

Équipe, CTO, produit, process, architecture : les explications existent déjà. Il faut distinguer les perceptions de la réalité.

« Nous avons grandi, mais pas notre façon de travailler. »

Ce qui fonctionnait hier peut devenir un frein dès que la taille, le produit ou les contraintes changent.

« Tout le monde travaille, mais rien ne devient prévisible. »

Le problème est parfois dans les interfaces et les décisions, pas dans la capacité de l’équipe à coder.

« Nous devons changer quelque chose, mais quoi ? »

Le bon changement peut être organisationnel, managérial, produit ou technique. Il faut le savoir avant d’agir.

Offre principale

Product & Engineering Diagnostic

Une intervention courte et immersive pour comprendre ce qui bloque, séparer les symptômes des causes et décider quoi changer, dans quel ordre.

10 500 € HT

au forfait · 7 jours de travail sur environ deux semaines
Ce que vous recevez
  1. 01Cartographie du système
  2. 02Symptômes ↔ causes
  3. 03Décisions critiques
  4. 04Plan d’action · 90 jours

Le diagnostic peut s’arrêter là, ou déboucher sur une transformation conduite avec vos équipes.La transformation →

Regarder assez large pour trouver le vrai problème. Descendre assez profond pour le vérifier.

Qui intervient

Je suis Charles Granet, ingénieur et dirigeant technologique. Vingt ans entre produit, software engineering, qualité et transformation d’équipes, dont cinq comme SVP Technology d’un groupe international de santé.

Je passe d’un échange avec un CEO à une revue d’architecture ou de code, puis je remonte au niveau où la décision doit être prise.

Ouverture dans l’analyse, fermeté dans la décision. J’écoute tout le monde sans adopter le récit de personne ; une fois le diagnostic posé, je ne dilue pas les décisions qu’il impose.

Le parcours →

Ce que je ne fais pas

  • Installer SAFe ou une autre méthode parce qu’il faudrait une méthode.
  • Placer des développeurs en régie, ou louer une direction technique au mois.
  • Vendre de l’expertise réglementaire : je connais ces contraintes, ce n’est pas mon métier.
  • Prolonger une mission sans objectif. La réussite, c’est une organisation qui fonctionne sans moi.

En pratique

Comprendre avant de changer.

La demande type

Le dirigeant d’une startup voit son équipe produit et technique s’enliser dans des tensions internes. Il ne sait pas si le problème vient de l’équipe, du CTO ou des process.

C’est exactement la situation pour laquelle le diagnostic existe : consulter, laisser parler, observer, chercher les signaux faibles — et construire une représentation du système avant toute conclusion.

Éditeur de logiciel de santé · diagnostic à la demande du CEO, puis transformation

Un client majeur met l’organisation sous tension.

Problème

Une petite société signe un client pharmaceutique hors de proportion avec sa taille. Retards et tensions s’accumulent ; l’équipe travaille plus sans que rien ne devienne prévisible.

Diagnostic

Le problème n’est pas l’effort mais la prévisibilité du delivery. Derrière : une sous-traitance mal découpée et une plateforme vieillissante, trop orientée ingénieur et pas assez métier.

Décisions

Des règles d’or sur les releases et le fonctionnement avec le client. Une sous-traitance autonome sur des modules indépendants. La migration engagée vers Python 3, puis une nouvelle plateforme pensée pour les chefs de projet.

Impact

Des releases et des plannings nettement plus prévisibles, un client rassuré. Le diagnostic a débouché sur une embauche, puis sur la transformation complète.

Je n’ai pas commencé par refaire la plateforme. J’ai commencé par comprendre le problème, puis traité dans l’ordre le delivery, l’organisation, la sous-traitance, la technologie et le produit.

Groupe international de santé · en poste de direction technique, après plusieurs acquisitions

Plusieurs plateformes héritées, une organisation à reconstruire.

Problème

Des acquisitions successives font entrer environ six plateformes et leurs équipes, dans plusieurs pays, sous un budget qui se resserre.

Diagnostic

Chaque plateforme examinée avec ses équipes. Pour chacune, une décision : conserver, arrêter, faire converger ou transformer.

Décisions

Restructuration d’une organisation engineering d’une cinquantaine de personnes. Arbitrages de staffing, de prestataires et de logiciels, réductions d’effectifs comprises.

Impact

Un portefeuille arbitré, une organisation restructurée, un budget engineering d’environ 5 M€ ramené à environ 3,5 M€ sans arrêter le produit principal.

L’enjeu n’était pas le budget en soi : il fallait décider ce qui devait continuer d’exister, comment organiser les personnes autour, et quelle technologie devait survivre.

Premier échange

Vous n’avez pas besoin de savoir exactement ce qui ne va pas.

Expliquez-moi ce qui a changé, ce qui vous inquiète et ce que vous avez déjà essayé. Trente minutes suffisent généralement pour savoir si un diagnostic a du sens.

Parler de votre situation