CTO de transition pour un produit logiciel médical
Je prends la direction technique de votre produit medtech — équipe, architecture, roadmap, conformité — le temps qu’il faut pour que la trajectoire tienne ensuite sans moi.
Quand un CTO de transition a du sens
Trois situations reviennent. Votre équipe technique avance sans direction : chacun fait ce qu’il sait faire, personne ne tranche l’architecture, et les arbitrages finissent sur le bureau du dirigeant, qui n’a pas les éléments pour décider. Votre CTO est parti, ou n’a jamais existé, et vous découvrez que la roadmap produit et le dossier réglementaire suivent deux chemins parallèles qui ne se croisent jamais. Ou vous préparez une levée, et l’investisseur cherche qui porte la crédibilité technique et réglementaire du produit. Dans les trois cas, recruter un CTO à temps plein prend des mois et suppose de savoir déjà ce que vous cherchez. La transition répond à l’urgence sans figer une décision de long terme : vous avez une direction technique opérationnelle immédiatement, et vous recrutez ensuite en sachant précisément quel profil il vous faut, parce que le poste aura été tenu et documenté. Cette mission n’a pas de sens si votre besoin réel est un renfort de développement. Je ne viens pas écrire des fonctionnalités à la place de votre équipe. Je viens décider, arbitrer, et répondre de la trajectoire technique devant votre comité de direction comme devant votre organisme notifié.
Ce que je prends en main
Je prends la responsabilité technique du produit, pas un rôle d’observateur. Concrètement, cela couvre quatre terrains. L’architecture d’abord : les choix structurants du logiciel, la dette qu’il faut résorber et celle qu’on assume sciemment, les interfaces avec le dispositif, avec les systèmes d’information hospitaliers et avec les traitements les plus sensibles, la stratégie de vérification. L’équipe ensuite : qui fait quoi, ce qui manque, ce qu’on internalise et ce qu’on confie à l’extérieur. Le recrutement, l’évaluation technique des candidats, la montée en compétence sur les exigences du médical — un excellent développeur qui n’a jamais travaillé sous IEC 62304 doit être accompagné, pas seulement informé. La roadmap : ce qu’on livre, dans quel ordre, et surtout ce qu’on ne livre pas. Dans le médical, chaque fonctionnalité ajoutée porte un coût réglementaire ; arbitrer sans ce coût en tête revient à préparer une mauvaise surprise au moment de l’évaluation. La conformité enfin : cycle de vie logiciel, traçabilité des exigences, gestion des risques, dossier de conception. Je ne délègue pas ce sujet aux affaires réglementaires pour le récupérer en fin de projet — il se construit dans le dépôt de code, au rythme du produit.
Ma place dans votre organisation
Je siège là où siège une direction technique : au comité de direction, dans les revues produit, dans les rituels de l’équipe. Le rythme se cale sur l’enjeu — quelques jours par mois pour tenir un cap et débloquer les décisions, ou un engagement bien plus soutenu sur une phase critique comme la préparation d’une évaluation. Nous le fixons ensemble au moment de la proposition, et nous le révisons quand la situation change plutôt que de le subir. Je travaille en direct avec vos développeurs. Je lis le code, je relis les demandes de fusion quand c’est utile, j’écris moi-même quand il faut lever un doute d’architecture. Ce n’est pas de la supervision à distance : une direction technique qui ne regarde jamais le code se fait raconter le produit au lieu de le connaître, et découvre l’écart au pire moment. Vis-à-vis de l’extérieur, je porte le discours technique devant vos investisseurs, vos interlocuteurs hospitaliers et votre organisme notifié. C’est souvent ce qui manque le plus : quelqu’un qui parle la langue du comité de direction et celle de l’ingénierie sans traduire l’une en approximations de l’autre.
Ce qui reste quand je pars
Une mission de transition se juge à ce qui tient sans moi. J’organise donc la sortie dès le début, pas au dernier trimestre. Les décisions d’architecture sont écrites, avec leur contexte et leurs conséquences, et pas seulement prises en réunion. Le cycle de vie logiciel est documenté et porté par l’équipe, pas tenu à bout de bras par une seule personne. Les exigences, les tests et les risques sont reliés dans un système que vos développeurs entretiennent au quotidien, parce qu’une traçabilité reconstituée après coup ne résiste ni à une revue sérieuse ni au premier changement de version. Sur le volet humain, je prépare votre successeur : soit un profil interne que j’accompagne vers le rôle, soit un recrutement externe pour lequel je définis le poste, je qualifie les candidats et je passe le relais. Dans les deux cas, le passage de témoin se fait en recouvrement, avec des décisions réelles à prendre, et non par un document laissé sur une table le dernier jour. Je n’ai aucun intérêt à rendre la mission indéfinie : un CTO de transition qui s’installe durablement a échoué à construire ce qu’il devait construire.
Parlons de votre produit
Un pair crédible, en comité de direction comme au bloc.