© alephcomo1 – Fotolia.com
« Trouver un bon CTO pour sa startup est plus compliqué que de lever 2 millions de USD »
L’un de mes anciens clients disait ceci :
Les startups qui réussissent ont trois profils types :
– un porteur d’idée
– un excellent développeur
– un excellent ux designer.Le porteur d’idée est aussi celui qui a la vision business, qui porte le potentiel et se charge d’acquerir les clients. Le développeur est capable de construire toute l’architecture de A à Z, en étant pragmatique. Il est aussi capable de recruter et de gérer d’autres développeurs. Enfin l’UX Designer est le responsable produit. C’est lui qui apporte une expérience utilisateur, qui prend en compte la vision du produit et qui fait que l’on aime le service ou le produit.
Si votre idée est géniale, en fait elle ne vaut rien tant qu’elle n’est pas exécutée. Autant je ne vois pas l’intérêt de protéger une idée, autant je trouve qu’il faut se battre pour trouver les bonnes personnes pour votre projet.
Depuis 3 ans, j’ai rencontré beaucoup de porteurs de projets. Chacun est à la recherche d’un CTO, un rôle pas forcément très clairement défini. Je vous propose de définir le rôle d’un CTO, puis de voir les pistes pour trouver et intéresser une personne à votre projet.
Qu’est-ce qu’un CTO ?
C’est un peu bidon comme titre. Un américain avec qui j’ai travaillé, m’a dit : tu es CTO le jour où ta startup est rachetée pour plusieurs millions de dollar. Avant, tu es juste un développeur.
Ce n’est pas tout à fait exact, mais en effet, tu es d’abord un développeur.
Pour une startup, croyez-moi, vous ne cherchez pas non plus un DSI (Directeur des systèmes d’information). Je vais essayer de vous dire ce que vous cherchez, et on appellera cela CTO à la fin, car on est en France.
Il existe tout d’abord plusieurs rôles différents, qui doivent s’adapter à vos besoins.
Il y a le CTO « CDD Chef Des Développeurs », le CTO « évangéliste visionnaire », le CTO « Mac Gyver.com » et enfin le CTO « ministre du redressement productif »
Rapidement :
- le CTO CDD « Chef des développeurs » est un meneur d’homme. Il sait recruter, monter une équipe. Il a un bon réseau, il comprend les technologies et c’est donc un assembleur de ressources humaines. Il s’appuiera sur le niveau technique des équipes et des prestataires.
- le CTO « évangéliste visionnaire » est un chercheur. C’est lui qui a une idée toutes les trois minutes, qui peut trouver la formule de l’eau chaude ou créer votre futur outil technique. C’est un développeur qui code, code et recode. Pas forcément un meneur d’homme, il est excellent dans son domaine technique. Par contre, il n’est pas forcément capable d’avoir une vision très business.
- le CTO « MacGyver.com » est quelqu’un d’expérience, capable d’assembler différentes solutions et « ça marche ». Parfois assez pour lever de l’argent et créer un vrai service. C’est ce qui est arrivé à Twitter, qui est passé de la stack Ruby à Java/Scala lorsque le projet a connu le succès que l’on sait aujourd’hui. Ce CTO sait un peu tout faire : du CSS, de l’admin-sys sur EC2, du recrutement, du suivi de projet.
- le CTO « Ministre du Redressement productif » est sans cesse à l’extérieur, en rencontre chez des investisseurs ou d’éventuels partenaires techniques. Il va gérer des développeurs en Inde, tout en signant un deal avec un fournisseur de CRM à Casablanca, afin d’intégrer en 2 jours le paiement automatique sur votre plateforme. Il fait un peu tout mais surtout à l’extérieur. Parfait devant des VCs, avec un réseau construit sur ses années passées chez un éditeur comme IBM ou Oracle.
Bref, et là j’ai encore d’autres visons… CTO ne veut pas dire grand chose. Surtout en France. Ne dîtes pas à un Américain « I’m the CTO ». Passez par la case « I’m the Lead Developer » et il vous écoutera encore mieux.
C’est un développeur. Typiquement, Emacs ou VI, slip ou caleçon, java ou php, il y a de la dualité dans cette personne. Et oui, elle code. Elle a peut-être 25 ans ou largement passé la quarantaine, mais elle code. Une mauvaise expérience dans une startup dans le monde médical m’avait montré qu’un CTO n’est pas un chef de projet. C’est d’abord un gars (ou une fille) qui sait écrire du code qui part en production.
Et donc du code qui part en production.
Pragmatique, simple et humble. Vous avez 10 000 EUR de love money : faut-il parier sur un développeur Java sans expérience du monde des startups ?
D’un côté, le développeur Java apporte son langage, la plate-forme et les pratiques d’industrialisation qui font de Java, un langage d’entreprise. De l’autre, une startup se doit d’avancer vite, et n’a pas les moyens d’avoir dès le départ une chaîne d’intégration ou du déploiement continu. Une startup, lorsque l’on est développeur, c’est une entreprise qui vit à crédit. Et ce qu’elle emprunte, c’est de la dette technique. Pas forcément autant de tests qu’un projet classique dans une banque, parfois un script manuel par-ci, par là… ce n’est pas parfait mais c’est suffisant pour avancer quelques semaines.
Donc si vous cherchez un CTO, oui vous pouvez prendre un développeur Java. La plateforme Java vous apportera un écosystème, des développeurs, un sacré ensemble de pratiques de développements. C’est la différence qui fera augmenter la valorisation de votre projet. Cadrez simplement pour qu’il ne mette pas en place dès le départ un bon nombre des pratiques d’industrialisation acquises au cours des années. Pensez à avancer et à valider les idées avant d’envisager une industrialisation plus classique.
Un CTO c’est aussi un chef d’équipe. Il faut avoir de l’empathie et de l’expérience pour comprendre le fonctionnement de chaque développeur. Idéalement, il doit être aussi en mesure de gérer et de suivre l’ensemble des métiers (intégrateur, web designer, graphiste) en collaboration avec l’UX Designer. Lorsque vous rencontrez votre futur CTO, voyez s’il a eu une expérience d’encadrement (appelée curieusement parfois « chef de projet« ).
Le rôle de CTO s’apparente à celui d’un capitaine de foot. On lui demande de mouiller le maillot et de coder avec les autres personnes de l’équipe. Pourquoi ? Et bien car c’est un peu aussi l’architecte, la personne qui réalise et qui porte la vision, et aussi le garde-fou. Il est donc indispensable que le CTO ait aussi une composante business, afin de pouvoir remonter des idées ou des améliorations pour les clients. Un pur développeur n’aura pas forcément cette capacité, et c’est difficile à mesurer.
Enfin et surtout, pour moi un CTO c’est aussi un entrepreneur. Lorsque je travaillais pour Zaptravel, presque toute l’équipe avait aussi réalisé un projet d’entrepreneur, avant de rejoindre la startup. Nous savions ce que le mot « acquerir un client » ou « faire un pitch à un VC » voulaient dire.
Un CTO n’a pas forcément besoin d’être une brute technique. C’est plus un rôle qui demande de l’expérience, pas mal de bons sens et aussi de l’humilité pour reconnaître lorsque l’on se plante. Et dans une startup, ça arrive tout le temps. Savoir vite changer de solutions techniques. Virer du code Scala avec des Enumeratees pour remplacer par un bout de Java et du PHP, des trucs que vous ne racontez pas aux copains, mais qui fait que la startup vit encore.
Comment intéresser un CTO au projet ?
Ce qui m’a convaincu de suivre des projets, c’est d’abord les personnes. Si je n’ai pas le feeling avec le créateur de l’entreprise, je préfère décliner le projet et passer la main. Je m’intéresse autant à la personnalité, qu’au parcours de la personne, à son réseau et à son expérience. Un vrai screening via LinkedIn/Viadeo. Comment voulez-vous vous investir dans un projet sérieusement sinon ?
Pour intéresser ensuite un CTO potentiel, oui l’idée du projet sera importante. Est-ce qu’il y a de l’innovation ? Que sera-t-il possible de faire mieux par rapport à d’autres concurrents ?
Il faut ensuite parler des moyens. Et là, je vais vous partager l’une des raisons pour lesquelles j’avais arrêté un projet il y a quelques années. Le responsable du projet ne voulait pas travailler avec des développeurs et souhaitait faire travailler des stagiaires. Or moi, les stagiaires je ne les vois pas comme des employés. Vous aussi non ? C’était tellement absurde, que le plan de financement avait prévu 1500 EUR par mois pour 3 stagiaires, ce qui en dehors d’être illégal, montrait la considération des créateurs de l’entreprise pour le métier de développeur. Auriez-vous envie d’être CTO dans ces conditions ?
Ensuite arrive une composante à bien préparer : le salaire et les parts.
Un CTO sait que son salaire ne peut pas être aussi important que lorsqu’il était « Directeur des projets et de l’innovation numérique de la SSII Croustille and Co.« . Si finalement le CTO ne veut pas de risques, et bien c’est peut-être un indicateur qu’il n’est pas prêt non ? Mais de là, à le payer comme un développeur junior… (*keuf* ça ne m’est jamais arrivé *keuf* *keuf*…).
Ce qui fait la différence, c’est la part que vous êtes prêt à partager avec votre futur associé. En dessous de 10%, un CTO vous dira d’aller voir ailleurs. Est-ce qu’il faut pour autant partir sur du 40% ou plus de votre projet ? Certainement pas. Alors que la dilution et d’autres investisseurs ne sont même pas dans la place, vous risqueriez de vous retrouver minoritaire du jour au lendemain. Idéalement, entre 15% et 30% selon la valeur technique de votre projet. Un simple projet de site web, sans complexité technique, ne doit pas donner autant de parts qu’un projet très technique (machine-learning, stats, big data, dashboard) où le CTO est indispensable.
Lorsque je rencontre des entrepreneurs, nous travaillons sur 3 scénarios : ça se plante rapidement, ça se plante pas trop rapidement ou le projet réussit. Et nous évaluons alors les sorties, et le risque que je serai prêt à prendre. Il faut vraiment parler argent à ce point de la discussion. Voyez avec le CTO s’il est partant pour un rachat. Imaginez que vous revendez votre site de recrutement à un gros groupe américain. Est-ce qu’il est prêt à rester comme salarié vers cette structure ou non ?
Enfin, et là je vais en mettre 3 couches : soyez pédagogique et super clair dans vos explications. Un entrepreneur qui ne sait pas expliquer correctement les BSPCA (Bon de souscription de part de créateur d’entreprise) passe à la trappe pour moi. En France, c’est le B-A-BA du « wannabe startuper ». Vous n’apprenez pas cela à l’école des startupers ?
Côté moyen, ce qui peut faire la différence c’est aussi les moyens techniques. Un CTO qui arrive avec un PC Dell en fin de vie lorsqu’il doit faire une présentation devant des VCs… non, vous ne voulez pas vivre cela. Curieusement, pas mal de monde croisé dans le milieu parisien travaille avec des Macs. Un CTO qui arrive avec un Mac : c’est bien. Un développeur qui arrive avec un Mac : c’est bien. Rien à faire que vous (les développeurs) trouviez cela choquant. Cherchez « Why do developers use mac« , regardez le matériel qu’utilise les conférenciers… en ce moment c’est Mac. Machine chère, fragile, truc de hypster… mais qui marche.
Comment garder son CTO ?
Si votre CTO est bon, il sera sollicité. Croyez-moi, avoir la vision technique, business et entrepreneur vaut beaucoup sur le marché. A vous de vous assurer que tout va bien et que la pierre angulaire de votre projet ne va pas partir dans 2 mois. Il vaut mieux réussir pas trop mal à plusieurs, que de se planter tout seul, car vous n’auriez pas voulu faire entrer au capital un autre associé.
Revoyez aussi régulièrement (tous les 3 mois) la situation et n’hésitez pas à vous séparer d’un CTO si le courant ne passe pas. Vous devez comprendre comment l’argent est investit. Si vous ne comprenez rien techniquement, c’est que votre CTO a cherché à trop vous expliquer ou pas du tout. Il faut un juste milieux, un entrepreneur doit pouvoir comprendre et expliquer les choix techniques de son CTO à des investisseurs.
Pour toi, développeur :
Prendre le rôle de CTO demande beaucoup d’engagements et de sacrifice. Il n’y a pas assez de bons développeurs en France. Si chacun est libre de juger la part de risque qu’il est prêt à prendre, j’encourage les développeurs à tenter cette aventure. Tout d’abord, vous pourrez mettre en oeuvre les technologies que vous souhaitez. Vous serez jugé durement si vous mettez 2 semaines à livrer. Vous ne serez pas jugé s’il n’y a pas l’ensemble des tests et que vous avez utilisé différentes technologies pour réussir. Les autres développeurs vous jugerons plus durement. Pas les entrepreneurs. Dès lors qu’une idée ou qu’une approche permet de « valider l’idée » sans dépenser du temps et de l’argent, vous serez un bon CTO.
Une startup doit vivre 10 fois plus vite qu’un éditeur, et 100 fois plus vite qu’une mission comme prestataire chez un client final. C’est violent. Vous devrez faire des sacrifices techniques, prendre des décisions puis changer d’avis. Votre capacité à risquer « raisonnablement » une idée vaudra de l’or. On vous demandera aussi de prendre le rôle de « voix technique de l’entreprise ». A vous de savoir présenter le projet à des développeurs pour grossir votre équipe. Vous verrez qu’il faut vraiment avoir une capacité à identifier et séduire les développeurs pour réussir. Cela veut dire qu’il faut trouver les moyens pour rassurer, pour aussi expliquer le déroulement au quotidien du projet et enfin les perspectives de l’entreprise.
Conclusion
Bon courage pour trouver un CTO. Trouvez d’abord un bon développeur, une personne que vous pourrez voir en vrai. Pas un gars dans un pays de l’Est, mais une personne sympa et expérimenté. Voyez selon l’importance de votre projet, selon les demandes des investisseurs, quelle place doit avoir ce développeur. Est-ce que vous êtes à même de recruter d’autres développeurs ? Est-ce que vous êtes au fait des dernières nouveautés du côté des bases NoSQL ?
Passez par la case freelance, vous pourrez rencontrer des profils comme nous, qui ne sommes plus à l’écoute du marché. Si demain je monte un projet, je ne ferai travailler que des indépendants. Ils gèrent déjà une entreprise, ils sont indépendants, il n’y a pas de relation hiérarchique, ils acceptent le risque, il est possible d’arrêter ou de continuer, et enfin ils sont moins chers que de prendre des salariés. Et pour ce qui est du niveau, croyez-moi, il y a un bon potentiel en France. Le revers de cette médaille, c’est qu’il faudra internaliser et séduire ces indépendants à un moment donné pour valoriser votre entreprise. Un fond d’investissement valorise l’équipe et n’aime pas les prestataires. A réfléchir aussi, mais cela ne doit pas vous empêcher de prendre des indépendants, même votre CTO, et donc de commencer à développer votre idée.
Enfin, et ce sera le mot de la fin : apprenez aussi à coder. Commencez par apprendre un peu le HTML+CSS, puis essayez d’installer un blog WordPress tout seul, en cherchant de l’information sur le net. Continuez en écrivant un peu de code avec du PHP, voyez comment cela peut fonctionner. Et ensuite arrêtez-vous là. Vous verrez que le métier de développeur est sacrément difficile.
0 no like
Article très intéressant. Il y a un autre CTO : le CTO+CEO+COO+tous les trucs en CxO. Les idées peuvent venir de gens techniques aussi 🙂
« De l’autre, une startup se doit d’avancer vite, et n’a pas les moyens d’avoir dès le départ une chaîne d’intégration ou du déploiement continu. »
Je ne partage pas trop ce point par contre. Mettre en place une chaîne d’intégration, même basique, va prendre une demi journée mais va à l’inverse faire gagner un temps énorme même lorsqu’on est seul à développer comme c’est mon cas actuellement.
Ça évite le syndrome « Qu’est-ce qu’on fait ? » si par chance l’entreprise marche et que l’on est amené à recruter (lire le livre de PKM créateur de Price Minister). Rien n’est prêt pour accueillir de nouveaux devs sur le projet du coup ça met encore plus de temps à mettre en place. Mais ça n’est que mon avis.
Un futur article pour trouver son futur associé commercial/marketing lorsqu’on est technique et qu’on a une idée ? C’est limite plus difficile étant donné qu’il est plus compliqué de jauger le niveau de la personne et ainsi fuir les « escrocs »…
Bonjour,
L’article est très bien, mais tout comme Chafik je ne partage pas le point de vue pour l’intégration et le déploiement continus. En effet ça paraît idiot mais c’est un très bon moyen d’accumuler rapidement une dette technique énorme, bref a minima il faut couvrir par l’intégration continue a minima le code métier (pour la couche présentation), et documenter le bazar.
Excellent article, merci !
Bon je vais en remettre une couche mais lire « une startup se doit d’avancer vite, et n’a pas les moyens d’avoir dès le départ une chaîne d’intégration ou du déploiement continu. » ça m’a vraiment fait bondir. Il se trouve que j’ai travaillé dans 2 startups (et participer à des créations d’entreprises technologiques avant que le terme startup n’existe) »récemment », de 2007 à 2008 puis de 2011 à 2012.
Dans les deux cas, la dette technique accumulée parce qu’un minimum de bonnes pratiques n’avaient pas été mises en place assez tôt était justement un frein à la « vélocité » et à la capacité de changement. J’ai participé à chaque fois à l’amélioration de ces pratiques et cela a toujours contribué à livrer plus vite.
Évidemment, faut pas passer 3 mois à mettre en place le truc mais de nos jours c’est tout de même assez facile, il existe de nombreuses offres de CI hostées dans le cloud. Donc non, pas d’excuse, surtout si vous êtes supposé être « CTO » donc porter la vision technique de l’entreprise : même à 1, avoir des pratiques correctes de développement et de déploiement ça peut faire la différence entre une startup qui livre et une autre qui ne livre pas. Après, on peut toujours livrer vite de la merde, ça reste de la merde.
Bon je ne rajouterai pas une couche alors, mais bon … 🙂
En fait je pense qu’une ds grandes qualités d’un CTO de startup sera de savoir faire simple, aller à l’essentiel. Quasi pas anticiper des besoins qui sont pas dans le radar, mais faire assez modulaire pour que toute modification ne soit pas trop impactante.
C’est très difficile de faire simple, de faire le bon niveau de simplicité.
Concernant les tests, je ne suis pas un grand fan de la couverture totale, mais de bien couvrir les parties métier importantes, ce qui est soit compliqué soit spécifique. et ça sert de doc.
Pour la doc : le minimum. Pas de commentaire, mieux faut du code clair.
Pour l’archi : pas de risque inutile, pas d’outil qui va te pomper beaucoup de temps. Un machin qui supporte les backups simple, qui t’empêche pas de dormir e la nave va.
Une scalabilité importante, beaucoup de cloud, à mon avis, ça a un coût qui n’est pas forcément super utile. Oui, important pour une appli mondiale et qui vise à avoir beaucoup d’utilisateurs. Mais si tu fais un petit service franco français en sass, pas besoin de chercher trop loin.
Et être à l’écoute des clients, du marché. Tout le temps.
Pour moi la règle d’OR d’une startup est de sortir son produit très tôt, pondre un truc qui donne envie par son idée mais sans toutes les fonctionnalités de la mort, parce qu’il y a 9 chances sur 10 que tout ce que tu anticipes ira à la poubelle
Ah oui un dernier truc : un CTO peut avoir un Dell en fin de vie, ça montre juste qu’il ne sait économiser la ressource de sa babasse 😉
Je pense que par chaine d’intégration, il entendait tests fonctionnels complets et automatisés.
-> sur l’intégration continue, et le reste: j’approuve, en effet, il faut aller très vite au début, on est plutôt en mode « recherche » et « prototype » et on peut parfois avoir besoin de changer rapidement d’approche.
Cela ne veut pas dire qu’il ne faut rien faire sur ces sujet, mais justement, tout est une question de balance.
-> sur la scalabilité par exemple: ca c’est un problème de riche! Si ton service doit être fortement scalable parceque tu a des millions d’utilisateurs, c’est que tu a probablement reussi ton pari de startup, et que tu a les moyens de dépenser pour être plus scalable.
Rien de pire que de prévoir un système « mega scalable » et de n’avoir attirer que 10.000 utilisateurs alors que peut être tu aurais du passer un peu plus de temps a explorer quelques features.
-> sur la partie « CTO », c’est effectivement assez bien décrit… J’ai été et suis CTO de 4 boites en général dès le tout début, et oui, il faut tout faire a la fois du codage et du pitch investisseur, mais c’est ca qui plait en général!