CIO fractionné en startup SaaS : structurer la technique avant d'en avoir les moyens

Une startup qui démarre n'a presque jamais les moyens d'un directeur des systèmes d'information (un « DSI ») à temps plein. Ce n'est pas forcément un problème, à condition de ne pas confondre « pas de DSI à temps plein » et « aucune gouvernance informatique ». C'est l'espace que couvre un « CIO fractionné ». CIO signifie « chief information officer », l'équivalent anglais du DSI, et fractionné veut dire qu'il n'intervient qu'une partie du temps. On y trouve la même exigence de méthode qu'avec un DSI classique, mais dimensionnée au stade réel de l'entreprise plutôt qu'à son ambition à trois ans.

La startup en question développe un logiciel vendu en ligne par abonnement (on parle de SaaS, pour « software as a service »), et elle était en phase d'amorçage, c'est-à-dire à ses tout débuts. La mission a démarré à la création de la société, avec un périmètre volontairement large : architecture informatique, choix de l'hébergement, infrastructure. Tout ce qu'une jeune entreprise qui vient de lancer son premier produit doit poser correctement une fois, plutôt que de rafistoler indéfiniment.

Dépendre d'un prestataire sans perdre la main

Comme beaucoup de startups, celle-ci avait confié le développement du produit à un prestataire extérieur. C'est un choix parfaitement rationnel quand on teste encore le marché : pas de salaire fixe tant que le modèle n'est pas prouvé. Le risque n'est pas dans la dépendance elle-même, mais dans une dépendance qu'on ne pilote pas : le droit sur le code qui reste chez le prestataire, une documentation qui n'existe que dans sa tête, une entreprise qui découvre, le jour où elle veut changer de prestataire, qu'elle ne peut pas le faire.

Le rôle du CIO fractionné n'est pas de remplacer le prestataire, qui continue d'écrire le code. C'est de garantir que la relation reste pilotable : suivi de la feuille de route, exigence de documentation, et surtout préparation de la sortie, avant qu'elle devienne urgente. Prévoir comment reprendre le développement en interne quand tout va bien coûte une fraction de ce que cela coûte quand la relation se dégrade et qu'il faut agir sous pression.

Préparer une équipe technique avant de pouvoir la recruter

Un des paradoxes du poste : une bonne partie du travail consiste à préparer une organisation que l'entreprise n'a pas encore les moyens de recruter. Cela revient à découper la fonction technique cible en plusieurs rôles (produit, développement, assistance, infrastructure) avant même d'avoir budgété la première embauche, pour que chaque recrutement futur s'insère dans une structure pensée, au lieu d'empiler des postes au gré des urgences.

Cette préparation sert dès le début : elle donne la base de la fiche de poste du premier profil technique, construite avec la direction plutôt que copiée d'un modèle générique. Une personne recrutée sur un poste pensé pour l'organisation cible reste plus longtemps qu'une personne recrutée pour éteindre l'urgence du moment.

Structurer avant la levée de fonds, pas après

L'erreur la plus fréquente dans une startup financée sans investisseurs extérieurs est de repousser la structuration technique après la levée de fonds (le moment où l'on fait entrer des investisseurs) ou après la validation du marché. C'est l'inverse qui protège le mieux l'entreprise. Arriver au moment de la croissance avec une infrastructure stable, un plan de sortie du prestataire déjà chiffré et une organisation cible déjà pensée change la vitesse à laquelle on peut accélérer quand l'occasion se présente.

La méthode appliquée ici suit le même déroulé que sur des projets bien plus gros : cartographier l'existant avant d'y toucher, cibler ce qui compte au stade actuel de l'entreprise, mesurer le risque de la dépendance au prestataire, préparer l'outillage de la structuration, puis piloter dans la durée. La taille de l'organisation change. La discipline de méthode, non.