Vous êtes CTO ? Nous avons compilé pour vous 10 erreurs à ne pas commettre pour rester en maitrise de votre, ou vos, projet(s).

Bien que non exhaustive, cette liste est basée sur nos vécus personnels, nous avons nous même commis certaines de ces erreurs et en avons rencontré d'autres dans le cadre de nos interventions en clientèle.

Certaines reviennent hélas très (trop) souvent et peuvent mettre en péril les projets, pourtant bien identifiées elle peuvent facilement être évitées.

Vous êtes prêts ? c'est parti !

1/ Adopter une posture de Lead Dev

Une erreur souvent commise par les CTO, notamment les "néo CTO" est de se tromper de posture. En effet même si le T signifie "technology" le C de "chief" pose la base du poste à savoir la direction technique. Il est plus facile pour un CTO, souvent dev ou lead dev précédemment de jouer les "super dev", présent sur tous les front, de la conception à la réalisation en passant par le mentorat auprès des membres de l'équipe. Le risque dans cette situation est de ne pas prendre assez de recul sur les sujets et ainsi être incapable d'avoir une vision d'ensemble pourtant importante à une prise de décision éclairée.

Un CTO doit avant tout avoir de bonnes connaissances techniques transverses permettant de prendre les bonnes décisions en termes d'architecture et de roadmap et cela bien plus que d'être expert d'une technologie. Il n'est pas rare de voir dans des équipes, des lead dev plus expérimentés sur le framework utilisé que son CTO.

Tout est une question d'équilibre :

• Trop proche de l'équipe technique, on perd la vision d'ensemble

• Trop proche de l'AMOA, on perd le contact avec la MOE "ceux qui font" et les potentielles difficultés rencontrées

• Trop proche de la direction, on perd la maitrise du projet

Vous l'aurez compris, le CTO est avant tout un catalyseur, il doit centraliser les besoins et les problématiques, synthétiser et donner les directions techniques adéquates.

2/ Foncer, tête baissée, avec sa stack technique habituelle

"Ca fait 15 ans que je développe en PHP dont 7 avec le framework Symfony, le prochain projet sera fait avec Symfony !". Partir sur une stack qu'on maitrise parfaitement, c'est rassurant mais est-ce vraiment la meilleure solution dans le contexte du projet ? Avant même de parler de choix technologique il est important de définir l'architecture technique du projet. Quelles briques techniques faut il mettre en place ? Quel type d'architecture (micro service, monolith, WSOA, ...) ? Comment les briques s'articulent ? Quelles sont les contraintes (temps réel, haute dispo, ..) ? Sur quel type de device le service sera-t-il utilisé (mobile, desktop, embarqué , ...) ? sont autant de questions auxquelles il faut répondre avant tout.

Si une équipe est déjà en place ou préssentie pour travailler sur le projet, de quelles compétences dispose elle ?

N'hésitez pas à challenger réellement votre choix "de coeur" et sélectionnez la stack adéquat, même s'il y a souvent plusieurs possibilités pour un même projet le choix doit être fait de manière pragmatique.

3/ Ne pas anticiper la scalabilité

Il est parfois difficile de prédire la charge à supporter et encore plus difficile de prédire le peak de charge à absorber, d'autant plus dans le cadre d'un nouveau projet. Pour autant la scalabilité de l'application doit être prévue dès le début, même si elle n'est pas tout de suite mise en place.

A défaut de mettre en place l'architecture de Netflix, capable d'absorber des dizaines de milliers de connexions simultanées, dès le début du projet, il convient d'anticiper les évolutions futures. Rien de pire que de devoir faire une refonte majeure après quelques mois lorsque le projet prend de l'ampleur, d'autant plus que parfois le succès arrive plus vite qu'on ne le croit !

Exit "les problèmes de riches" dont vous parleront certains, lorsque la technique est un frein au développement du business, personne ne passe de bons moments et personne n'est vraiment "riche" à ce stade 🙂

Alors pensez grand dès le début mais restez dans une démarche progressive et pragmatique. En clair, ne vous mettez pas de freins sans pour autant anticiper les besoins, mais ça on en parle dans le prochain chapitre.

4/ Trop anticiper la scalabilté

Certes il faut voir grand, mais voir trop grand n'est pas non plus recommandé. Réaliser une architecture très complexe afin de gérer des pics de charges hypothétiques aura pour unique effet de r-complexifier le code et ralentir la phase de développement, et ce, potentiellement pour rien. A moins d'avoir des éléments factuels laissant présager de la charge à absorber, c'est le cas lors d'une refonte, nul besoin de mettre la charrue avant les boeufs. Si l'architecture est pensée pour évoluer en fonction des besoins en terme de charge, il sera temps de mettre en place ces améliorations en temps voulu.

Finalement, la scalabilité, au même titre que l'évolutivité de l'application, est une histoire de dosage.

5/ On testera plus tard

Il est parfois tentant de rogner sur la phase de test pour gagner du temps et sortir le projet plus rapidement. Ce temps "gagné" est souvent perdu au centuple au fur et à mesure que le projet évolue. Pire! plus on attends, moins on a envie de revenir sur le code pour écrire des tests.

La encore tout est histoire de dosage, rien ne sert d'écrire des tests partout surtout s'ils ne sont pas pertinents et visent uniquement à afficher fièrement 100% de code coverage.

Faire des tests cohérents (cas nominal, cas limite, cas d'erreurs, ..) sur les fonctionnalités clefs et les mettre à jours avec le code est le mininum requis pour un projet pérenne.

Le TDD est une approche permettant de garantir des jeux de test pertinents et une couverture convenable, cependant cette approche n'est pas la seule acceptable.

En plus des tests unitaires, il est important de réaliser des tests d'intégration ou tests fonctionnels automatiques, afin de garantir, notamment, la non régression de fonctionnalités clefs au fur et à mesure des développements.

Par exemple valider le tunnel d'achat d'un site e-commerce devrait être un pré-requis et doit donc être intégré dans les tests de non regression.

Automatisez le tout

Ne vous faites pas confiance, automatiser le processus à l'aide d'une CI/CD afin de garantir que ces tests seront systématiquement réalisés avant chaque release. L'erreur est humaine, alors limitez les interventions humaines dans vos processus critiques.

Plus d'excuses pour ne pas tester son code, prenez l'habitude dès le début afin de ne pas accumuler de dette.

6/ Ayatollah du code

Avoir un code propre permet :

1. Une meilleure compréhension utile à tous les membres de l’équipe et facilite l’entrée de nouveaux arrivants

2. Facilite le debug

3. Limite les bugs

Cependant attention à ne pas tomber dans le fétichisme du code propre. Certes ce n’est jamais “trop propre” en revanche refactoriser des fonctionnalités juste pour que ce soit “un peu plus respectueux des bonnes pratiques” n’est pas toujours utile.

Il arrive même parfois que cela soit contre productif et amène à des régressions ou des temps de dev tres longs.

On ne le répétera jamais assez mais tout est question de mesure ! Accumuler de la dette technique au motif qu’il faut aller vite n’est pas une option pérenne, passer 40% de son temps a faire et refaire non plus.

Jugez de ce qu’il est acceptable de garder en l’état et faites des notes pour plus tard, planifiez les travaux en les mettant dans des jalons identifiés afin d’éviter de les repousser à jamais.

7/ Le dernier qui parle à raison

Vous êtes le patron technique, vous êtes également le point de contact pour les demande entrantes. Bug evolution, nouveaux projets, tout passe par vous et vous devez garantir l’homogénéité de l’architecture technique tout en étant garant du planning. Que de responsabilités dans un environnement plus ou moins pressurisant. Chaque demande est toujours formulée comme étant une “urgence vitale” à réaliser pour la veille, dans ce context difficile de tenir un planning et pire, difficile de garder un code propre et cohérent.

Votre job est avant tout de fluidifier les travaux techniques en anticipant au maximum les fonctionnalités, chose impossible si la roadmap et les priorités changent sans cesse.

À vous de rationaliser les demandes et les challenger afin de ne pas chambouler le planning et l’architecture en place. Si cependant une restructuration profonde est nécessaire, pas de problème définissez clairement les besoins et les raisons de cette refonte afin de faire les meilleurs choix pour y répondre.

8/ Faire de la sécurité par le déni

Sécuriser une application certes ça ne s’improvise pas mais, comme pour la qualité de code, il existe des bonnes pratiques en vigueur.

La plupart des frameworks intègrent bon nombre de mesures de sécurité par design.

Pour autant se reposer sur ces mesures n’est pas suffisant, il convient de mettre en place d’autres mesures de sécurités plus ou moins drastiques en fonction de la nature des données à sécuriser.

Il va sans dire qu’une application destinée à collecter et traiter des données bancaires ou de santé sera plus critique qu’une plateforme d’actualités.

Parmis les mesures de sécurité de base qu’il convient de mettre en place, on peut citer à titre d’exemple la mise en place d’un token d’authentification sur vos api ou encore un csrf token sur vos formulaire.

Sans tomber dans la paranoïa il convient d’être systématiquement méfiant quant aux intentions de vos utilisateurs et mettre en place les contres mesures adéquates.

Le pire que vous puissiez faire et d’employer la technique de “la sécurité par le déni”.

Cela consiste à mettre la tête dans le sable et partir du principe que les utilisateurs ne sont pas malveillants ou qu’ils n’ont aucun intérêt à l’être.

Pour reprendre la punchline favorite de cet article : tout est question de mesure ! Securisez vos données et soyez critiques de vos propres mesures. Tentez de vous hacker vous même, vous connaissez le code et ses failles.

Si besoin, faites appelle a des spécialistes des tests de pénétration, vous aurez alors un état des lieux exhaustifs des failles exploitables et leur criticités.

9/ Ne pas monitorer son application

Ne pas monitorer une application en production revient a prendre l’autoroute sans tableau de bord sur son véhicule.

Impossible de savoir de manière factuelle ce qu’il se passe, ni d’anticiper les problèmes. Il existe énormément d’outils de monitoring, plus ou moins complets, plus ou moins chers.

Le minimum syndical est d’avoir une vision claire de la charge de l’infrastructure, des statistiques d’usage de l’application et bien entendu, une vision claire des erreurs survenues sur l’application.

Ces informations vous permettent de valider le bon fonctionnement de votre produit, d’être alerté en cas de problème et de suivre l’usage qui en est fait. Cela vous permettra d’anticiper de potentiels problèmes, en cas de montée en charge par exemple et de pointer les erreurs survenues.

En clair, pas de MCO sans monitoring.

10/ Surestimer ses capacités

Vous êtes CTO, pas maître de l’univers. L’attaque de ce chapitre est volontairement provocateur pour éveiller votre conscience. Difficile pour l’ego d’avouer sa propre incapacité à faire quelque chose, surtout lorsqu’on occupe un poste à responsabilités.

N’oubliez pas la célèbre réplique de Steeve Jobs “Cela n'a aucun sens d'embaucher des gens intelligents et de leur dire quoi faire; Nous embauchons des gens intelligents pour qu'ils puissent nous dire quoi faire”, quelle humilité...

Sachez vous entourer de gens talentueux et surtout n’hésitez pas a faire appel, ponctuellement, à des personnes extérieures pour traiter un sujet précis ou bien auditer le travail de vos équipes.

La remise en question, sans excès, l’humilité et la conscience de ses propres limites semble être la recette du succès.

De plus, valoriser vos collaborateurs en leur faisant confiance et en leur montrant que leur avis est pris en compte les fidélisera à vos côtés.

Cerise sur le gâteau, déléguer et faire confiance réduit la charge qui pèse sur vos épaules, c’est un cercle vertueux.

Conclusion

Bien de non exhaustive, cette liste des 10 erreurs à ne pas commettre constitue une bonne base.

Nous l’avons construite sur la base de nos experiences, avec le temps ce sont des points de vigilance que nous surveillons systématiquement dans le cadre de nos projets / missions.

Et vous, qu’en pensez vous ? Avez vous deja commis ces erreurs ? Quel est votre retour d’expérience ?

Peut-être avez vous fait d’autres erreurs que vous aimeriez nous partager. Engageons la discussion 🙂