Une PME qui n’a personne pour arbitrer ses choix techniques finit toujours par les faire arbitrer par ses prestataires. Le CTO à temps partagé répond à ce problème-là : donner à l’entreprise une direction technique quelques jours par mois, sans recruter à temps plein un profil qu’elle ne saurait ni occuper ni évaluer.
Le malentendu le plus répandu porte sur son objet. On l’imagine en développeur expérimenté qu’on paierait moins cher parce qu’il vient moins souvent. Ce n’est pas son rôle. Un CTO à temps partagé ne sert pas à coder moins cher : il sert à décider juste avant de dépenser.
Ce que fait un CTO à temps partagé (et ce qu’il ne fait pas)
Son périmètre tient en trois verbes.
- Arbitrer. Construire ou acheter, tel prestataire ou tel autre, refondre ou prolonger. Des décisions dont le coût se compte en années d’engagement, et qui se prennent souvent sur la seule parole de celui qui vend.
- Cadrer. Traduire un besoin métier en un cahier des charges qu’un prestataire peut chiffrer sans l’interpréter, et fixer à l’avance les critères auxquels on reconnaîtra que le travail est fait.
- Contrôler. Relire un devis, une architecture, un contrat de maintenance ; vérifier que ce qui est livré correspond à ce qui a été acheté. C’est la part la plus négligée, et celle qui rembourse le plus vite la mission.
Ce qu’il ne fait pas se dit aussi clairement. Il ne tient pas le clavier à la place de l’équipe de développement, il n’assure pas le support des postes de travail, il ne remplace pas un prestataire d’infogérance. S’il le fait, la mission a été mal cadrée : l’entreprise paie une fonction de direction pour obtenir une capacité d’exécution, et n’a finalement ni l’une ni l’autre.
La frontière avec la direction des systèmes d’information mérite d’être tracée. Le CTO porte la technologie du produit ou du service que l’entreprise vend ; le DSI porte l’informatique qui la fait fonctionner — postes, messagerie, logiciels de gestion, sécurité. Dans une PME, les deux se confondent souvent, et le DSI à temps partagé répond à la seconde question bien plus qu’à la première.
Cinq signaux qu’une PME a besoin d’une direction technique
La taille de l’entreprise ne dit presque rien. Les signaux utiles sont ailleurs.
- Les devis ne sont pas comparables. Deux prestataires répondent au même besoin avec des écarts que personne en interne ne sait expliquer. La décision se prend alors sur le prix, ou sur la sympathie.
- Le produit dépend d’une seule personne. Un développeur, salarié ou indépendant, est le seul à comprendre le code. Son départ serait un arrêt.
- Les projets se terminent sans que personne sache s’ils ont réussi. Faute de critères écrits au départ, la livraison vaut réception.
- La dette technique est devenue un sujet de direction. Chaque fonctionnalité nouvelle coûte plus que la précédente, et personne ne sait dire pourquoi.
- Une levée de fonds, une cession ou un audit approche. Quelqu’un va poser des questions techniques précises, et l’entreprise n’a personne pour y répondre avec autorité.
Certains signaux montrent à l’inverse que ce n’est pas le moment. Une entreprise dont l’informatique se limite à des logiciels du marché bien choisis n’a pas besoin d’une direction technique : elle a besoin d’un bon prestataire et d’un contrat clair. Et une entreprise dont les décisions techniques sont devenues quotidiennes a déjà dépassé le temps partagé : il lui faut quelqu’un sur place.
CTO à temps partagé, CTO freelance, CTO externalisé : les différences
Les trois termes circulent comme des synonymes. Ils ne décrivent pas la même chose, et la différence tient moins au contrat qu’à ce que l’entreprise achète réellement.
| Formule | Ce qu’on achète | Rythme | Risque principal |
|---|---|---|---|
| CTO à temps partagé | Une fonction de direction, quelques jours par mois | Régulier, dans la durée | Un périmètre qui glisse vers l’exécution |
| CTO freelance | Une personne, pour une mission ou une phase | Intense, puis rien | Une dépendance à un individu, sans relais |
| CTO externalisé | Une fonction confiée à un cabinet, avec continuité d’équipe | Fixé par le contrat | Une distance au métier si l’interlocuteur change |
Le CTO freelance est souvent le bon choix pour une mission bornée : auditer un code avant une cession, cadrer un projet, recruter une première équipe. Le CTO externalisé apporte ce qu’un indépendant ne peut garantir, la continuité si la personne change. Le temps partagé se distingue par sa durée : il installe une fonction plutôt qu’il ne réalise une mission.
Le choix dépend donc de la question posée. Une question ponctuelle appelle une mission. Une question qui revient chaque mois appelle une fonction.
Comment se déroule une mission : rythme, livrables, gouvernance
Une mission de direction technique à temps partagé commence rarement par la technique. Elle commence par un inventaire : ce que l’entreprise a construit, acheté, confié, et à qui. Sans lui, tout arbitrage se fait à l’aveugle.
Le rythme se fixe ensuite, et il compte davantage que le volume. Une présence régulière et prévisible — un jour fixe chaque semaine, ou deux jours par mois à dates connues — vaut mieux qu’une disponibilité large mais imprévisible : équipes et prestataires apprennent à préparer les décisions pour ce rendez-vous.
Les livrables attendus sont peu nombreux, et ils doivent exister par écrit :
- une cartographie de l’existant — applications, prestataires, contrats, accès — tenue à jour ;
- une feuille de route technique courte, reliée aux objectifs de l’entreprise et à son budget ;
- un registre des décisions : ce qui a été tranché, pourquoi, et ce qu’on a écarté ;
- des critères de réception pour chaque projet confié à un prestataire.
La gouvernance, enfin, doit être explicite. Le CTO à temps partagé rend compte à la direction générale, pas à un prestataire ni à un chef de projet. Il a accès aux contrats et aux factures. Sans cet accès, il conseille ; il ne dirige pas.
Lorsque la feuille de route conduit à construire, les deux rôles gagnent à rester distincts : celui qui cadre et contrôle doit pouvoir dire non à celui qui développe. C’est pourquoi, chez Maeliom, le cadrage relève de Maeliom Consulting et la réalisation de Maeliom Build — et pourquoi un cadrage peut conclure qu’il ne faut rien construire.
Les limites du modèle
Le temps partagé a trois limites, et une mission honnête les nomme dès le départ.
- La réactivité. Un incident un jour sans présence attend. Le modèle suppose un prestataire ou une équipe capable de tenir l’exploitation, avec des règles d’escalade écrites.
- La profondeur. Quelques jours par mois permettent d’arbitrer et de contrôler, pas de connaître chaque ligne du code. Sur les sujets pointus, le CTO à temps partagé mobilise un spécialiste ; il ne le remplace pas.
- La durée. Quand les décisions techniques deviennent quotidiennes, le temps partagé ralentit l’entreprise au lieu de la protéger. C’est le signe qu’il faut recruter.
Ce dernier point est le plus important. Un CTO à temps partagé qui fait bien son travail prépare le recrutement qui le rendra inutile : il rédige la fiche de poste, participe aux entretiens, transmet la cartographie et le registre des décisions à celui qui prend la suite. Pour une jeune entreprise, le CTO as a service pose la même question sous un autre angle : ce qu’il faut trancher avant de recruter.
Questions fréquentes
Combien de temps un CTO à temps partagé consacre-t-il à une PME ?
Il n’existe pas de volume standard. Le rythme se fixe d’après le nombre de décisions à prendre et de prestataires à piloter. Ce qui compte est la régularité : une présence prévisible permet aux équipes de préparer les décisions pour ce rendez-vous.
Un CTO à temps partagé peut-il développer lui-même ?
Il le peut, mais ce n’est pas l’objet de la fonction. Une mission qui glisse vers l’exécution prive l’entreprise de ce qu’elle achetait : quelqu’un qui arbitre, cadre et contrôle le travail des autres.
Quelle différence avec un DSI à temps partagé ?
Le CTO porte la technologie du produit ou du service vendu ; le DSI porte l’informatique interne — postes, logiciels de gestion, sécurité, prestataires. Dans une petite structure, une même personne peut couvrir les deux, à condition de savoir laquelle des deux questions elle traite.
Quand faut-il remplacer le temps partagé par un recrutement ?
Quand les décisions techniques deviennent quotidiennes, ou quand l’entreprise construit elle-même son produit avec une équipe interne. Le temps partagé sert alors à préparer ce recrutement et à transmettre ce qui a été documenté.