Une direction technique, sans recruter un CTO à plein temps
Beaucoup de sociétés prennent des décisions techniques structurantes sans personne dont c'est le métier. Le dirigeant arbitre seul, ou délègue à un prestataire qui a un intérêt dans la réponse. Un CTO à la demande comble ce trou quelques jours par mois.
Le problème que cela règle
Une décision d'architecture, un choix de prestataire ou une reprise de code se décident une fois et se paient pendant cinq ans. La plupart des sociétés de vingt à deux cents personnes n'ont personne pour les arbitrer : le dirigeant tranche à l'instinct, ou demande son avis au prestataire qui va vendre la prestation.
Recruter un CTO règle le problème et coûte un salaire de direction, plus trois à six mois de recrutement. Pour beaucoup, le besoin réel est deux à quatre jours par mois de jugement senior, pas un temps plein.
Ce que fait concrètement le rôle
Arbitrer les décisions qui coûtent cher à défaire : choix de stack, découpage applicatif, achat contre construction, plan de migration. Relire ce qu'un prestataire propose avec l'œil de quelqu'un qui n'a rien à vendre sur ce lot. Mettre en place ce qui manque presque toujours : des environnements, une CI, une revue de code, une gestion des accès.
Le rôle rend aussi lisible ce qui ne l'est pas. Un dirigeant non technique doit pouvoir dire où part le budget technique et ce qui arrive au prochain trimestre, sans traduire un jargon qu'on lui a servi.
Ce que ce n'est pas
Ce n'est pas un développeur. Si vous avez besoin de quelqu'un qui écrit le code, c'est de la régie, et c'est facturé autrement. Ce n'est pas non plus un chef de projet : le rôle décide de la direction technique, il ne pilote pas un planning au quotidien.
Et ce n'est pas un moyen déguisé de vous vendre une équipe. Un CTO à la demande qui recommande systématiquement son propre employeur ne vous sert à rien. Si le bon arbitrage est de garder votre prestataire actuel, ou d'internaliser, c'est ce qui sera dit.
Due diligence technique
Le second usage du rôle est ponctuel : évaluer une base de code avant une acquisition, une levée ou une reprise. Ce que fait vraiment le code contre ce que dit la documentation, la dette réelle, les dépendances abandonnées, ce qui arrive si la personne qui l'a écrit part.
Le livrable est un avis écrit avec ce qui est solide, ce qui est réparable et ce qui devra être réécrit, chiffré en charge plutôt qu'en adjectifs.
Le rôle se dimensionne en jours par mois, pas en équivalent temps plein. En dessous d'un certain seuil il n'y a pas assez de continuité pour être utile.
- Arbitrage récurrent2 à 4 jours par moisDécisions d'architecture, revue des propositions, point mensuel avec la direction.
- Mise en placeMission courte, puis récurrentEnvironnements, CI, revue de code et gestion des accès quand rien n'existe.
- Due diligence techniqueMission ponctuelle, 1 à 3 semainesAvis écrit sur une base de code avant acquisition, levée ou reprise.
- Encadrement d'une équipe interne2 à 6 jours par moisPour une équipe junior sans senior pour la relire ni la faire progresser.
Questions fréquentes
- À partir de quelle taille cela a du sens ?
- En pratique à partir du moment où il y a du logiciel en production dont l'entreprise dépend, et personne en interne dont c'est le métier de l'arbitrer. Cela arrive souvent bien avant vingt personnes.
- Qu'est-ce qui se passe si votre avis est de ne pas travailler avec vous ?
- Alors c'est ce que vous obtenez. Un rôle d'arbitrage qui recommande toujours son propre employeur n'a aucune valeur, et se repère en deux réunions.
- Est-ce que le rôle recrute pour nous ?
- Il peut cadrer le besoin, écrire la fiche et faire passer la partie technique des entretiens. Le recrutement lui-même reste chez vous ou chez un cabinet.
- Combien de temps dure un engagement type ?
- Assez pour que la continuité serve à quelque chose, donc plusieurs mois, avec un préavis court. Une due diligence est l'exception : une à trois semaines, avec un livrable et une fin.
Décrivez la décision qui bloque
Expliquez à l'assistant de cadrage ce qui doit être arbitré et sous quel délai. Il pose les questions qu'un ingénieur senior poserait, puis renvoie une estimation avec un format et une date de démarrage.
Cadrer une mission- Dette technique : la comprendre, la chiffrer, la traiterLa moitié de ce qu'on appelle dette technique n'en est pas. Comment distinguer un emprunt assumé d'un simple désordre, comment rendre le coût lisible à un dirigeant, et pourquoi une partie de cette dette ne mérite pas d'être remboursée.
- Externalisation informatique : définition et modèlesLe mot recouvre cinq dispositifs qui n'ont presque rien en commun, et la plupart des contrats ratés commencent par deux parties qui l'emploient pour deux choses différentes. Ce que chacun veut dire, qui porte le risque, et quand il ne faut pas externaliser.
- Devis développement logiciel : les comparer sans erreurDeux devis pour le même brief peuvent varier du simple au triple sans que personne ne mente. Voici comment les ramener à une base commune de jours, de taux et de périmètre avant de signer.
- Forfait ou régie informatique : que choisir, et le podLe modèle de contrat décide qui paie quand le périmètre se révèle faux. Nous comparons forfait, régie et pod avec nos propres conditions : grille publique de 150 à 450 EUR par jour, pods de 15 à 40K par mois.
- Régie informatiqueDes ingénieurs nommés intégrés à votre équipe, sur la journée de travail européenne, contractualisés depuis la Belgique.
- Nearshore ou offshoreComparaison directe pour les équipes européennes qui externalisent déjà et envisagent de se rapprocher.
- Externalisation informatiqueUn groupe dédié qui porte la livraison de bout en bout, de l'architecture au maintien en production.
- Infogérance cloud et ITCloud, pipelines, domaines, messagerie et accès, tenus par l'équipe qui connaît aussi le code.
- Migration cloudInventaire, découpage en lots et retour arrière testé, pour une bascule qui ne dépend pas de la chance.
- Infrastructure as codeDes environnements décrits en code, revus et recréables, plutôt que configurés à la main une fois pour toutes.
- Expert IA et chatbotDes modèles intégrés à du logiciel qui tourne, avec la franchise sur ce qui ne marchera pas.
- Expert ShopifyPour les boutiques Shopify qui doivent parler à un ERP, un stock ou un flux de paiement.
- Big data et donnéesEntrepôt, pipelines et réconciliation, pour des chiffres auxquels on peut se fier.