Créer un site web et ou une application c’est assez simple. Permettre à une équipe de travailler sur plusieurs parties en parallèle demande quelques aménagements. Intégrer des changements rapides sans tout casser nécessite de la rigueur. Monter en charge et atteindre le succès peut être une épreuve parfois, et souvent impose quelques week-end difficiles et une ou deux nuits blanches. Mais faire en sorte que tout ce mette en place, résiste à la montée en charge, permette de garder un rythme de vie correcte et être en plus capable d’intégrer rapidement des équipiers dans l’aventure, ça se prépare dés le début.
Dans cette série d'article je vais parler de mes expériences personnelles en terme de développements logiciels et en particulier les développements de logiciel grand public (site web) et mes expériences de mises à l'échelle réussies ou ratées.
TL;DR: choix de technologies en fonctions des possibilités en interne et via des recrutements; soigner ses talents; risque de la spécialisation; méta-conception à penser dès le début; lead dev un rôle clé.
Le recrutement et la technologie
Je me souviens d’une interview pour préparer le Forum PHP avec l’AFUP où la question était: « pourquoi avoir choisi PHP comme langage de programmation ? »
J’ai répondu du tac au tac: c’est un langage facile à apprendre, proche du C dans son écriture, avec une main d’œuvre très importante facilement disponible et des coûts en consultant au niveau de la moyenne. Facebook l’utilisait (2008-2015) et arrivait visiblement à supporter les montées en charge.
C’est important lorsqu’on choisi une technologie de tenir compte du marché et pas juste des appétences des équipes de développement.
D’un côté on a les devs qui souhaitent utiliser la dernière technologie et le dernier langage, d’un autre ceux qui « on toujours fait comme ça et ne comprennent pas pourquoi on devrait changer ». On a aussi les CTOs et le Business qui ne souhaitent pas investir dans des nouveaux concepts et ne sont pas près à absorber les coûts liés aux changement et encore moins ceux liés à l’apprentissage. Ici je parle principalement du coût en temps nécessaire pas du coûts des formations.
Alors dans tout ça comment faire son choix? Comment déterminer le juste milieu?
Un des premiers critères assez facile et qui parle au C-level est le coût de la main d’œuvre. Oui comme ça qu’on en parle au niveau des staffs d’entreprises.
Les devs ce sont les mineurs d’hier, les ouvriers du code, les nouveaux plombiers/pompiers/hommes à tout faire, remplaçable à l’envie et disponible par pelletée entière sur le marché du travail… les écoles en fabriquent des milliers chaque années et moins cher plus on s’éloigne vers le sud ou vers l’est.
Oui… peut-être… mais pas tout à fait.
Un dev ça a plusieurs origines et plusieurs cultures, un dev ça se rencontre, ça se recrute, un dev ça ce conçoit, c’est beaucoup plus qu’une ressource, c’est un écrivain, un lettré, un artiste du code, un penseur, un concepteur, un architecte, un mathématicien et un physicien, un ingénieur, un analyste, un statisticien, un créateur. C’est tout ça si on lui en donne l’opportunité, si il a la chance de faire de belles rencontres et si il est amoureux de son métier. Et c’est là que le choses peuvent devenir compliquée et que mettre des artistes sur une lignes de production logicielle, c’est mettre des artisans dans une usine de voiture … ça va les rendre malheureux et leurs mains qui étaient de l’or vont devenir des pousses boutons…
Dans toutes les entreprises qui ne sont pas nativement des entreprises ITs (et même dans ces dernières) les devs sont considérés comme des ressources et dès qu’on monte à l’échelle, qu’on devient une grosse, grosse boîte ou simplement qu’on double la taille de l’équipe, les artisans d’hier doivent se spécialiser et en se spécialisant, laisser tomber certains aspects de leur boulot pour le laisser à d’autres.
Alors évidemment avec les équipes qui grandissent il est possible de bouger vers du management (ce qui peut être une bonne chose) mais tout le monde n’en a pas envie et tout le monde n’est pas forcément bon dans ce domaine. Et c’est très bien comme ça.
Donc il reste deux choix aux développeurs: partir ou accepter de se spécialiser.
Quel est le problème de la spécialisation? ça peut vite devenir monotone, ça peut devenir très rapidement trop limitatif. Bref, ça devient chiant! Mais si c’est bien amené, bien préparé, bien pensé au niveau du comité de direction, ça peut devenir un secteur à part entière! Une filiale, une spin-off …
Choisir les technologies c’est donc penser avant tout aux talents disponibles en interne et sur le marché, comprendre les tendances, comprendre les appétences et les accompagner et parfois même en faire une entreprise à part entière.
Oui mais comment faire une ligne de production logicielle?
On imagine souvent une ligne de production qui ressemble à une ligne d’usine ou à du Fordisme logiciel.
Ça peut être différent. Par exemple avec le principe: « si je dois le faire deux fois, c’est une fois de trop », vous pouvez concevoir avec votre équipe, et c’est important de le faire dès le départ, l’usine vous même!
Vos artisans resterons des artisans mais inventerons les machines qui réaliseront les tâches répétitives.
C’est l’avantage de l’informatique c’est qu’il est possible de concevoir les produits qui conçoivent les produits… et faire de la meta-conception.
Les lignes de production d’usine sont en effet remplacée par des robots pour les parties les plus simples et répétitives. L’avantage des devs c’est qu’ils sont capable de directement construire les robots et c’est là qu’il faut faire des choix et des arbitrages judicieux: construire tous les robots? Acheter certain? Construire en imaginant de les concevoir pour d’autre et donc d’engendrer de la valeur? Il faut y être préparer.
C’est quoi la meta-conception?
C’est penser dès le départ à automatiser chaque aspect du métier de développeur tout en permettant aux développeurs de construire eux même les robots qui les remplaceront, ça signifie que leur métier évolue vers des aspects beaucoup plus complexe et porteur de défis et qu’on réduit la partie souvent répétitive de leur métier de départ (mais ils ne le savent pas encore). Et c’est là qu’il faut un bon support du recrutement et du management. Un support pour identifier et accompagner le changement. Un support qui permet de se poser les bonnes questions. Un support qui autorise de se poser la question à chaque fois: Est-ce notre cœur de métier? Est-ce que ça existe déjà sur le marché? Combien d’équivalent temps plein coûte ce produit?
C’est important de systématiquement mesurer le coût et d’être transparent là dessus.
Ensuite dès qu’on automatise quelque chose, ça peut signifier de nouvelles opportunités pour l’entreprise: un nouveau secteur d’activité ou un séparation d’activité. (Il faut être prêt à accepter les deux).
Un exemple simple. La société souhaite concevoir un site web avec un formulaire pour un concours. Soit on prend un produit tout fait, soit on développe sont propre produit.
Un petit tour du marché des produits tout fait et une estimation de l’intégration vont permettre d’avoir une première borne pour estimer à partir de quand il faut concevoir soit même. Cette borne est à garder à l’esprit tout le long de la vie du produit.
Si on développe son propre produit (pour des raisons de cœur de métier, d’intégration ou simplement parce que l’équipe se sent motivée et qu’on n’explose pas les coût d’une solution toute faite) il faut penser à la mise à l’échelle dès le début.
- Mise à l’échelle pour les performances
- Vitesse d’affichage
- Montée en charge (quid si 1000000 d’utilisateurs)
- Mise à l’échelle pour les modifications
- Temps pour faire des modifications
- Temps de déploiement
- Tests intégrés
- Mise à l’échelle pour l’architecture et la modularité
- Architecture N-tiers
- Micro-services
- Dockerisation
- Déploiement sur des clusters de machines
- Librairie et documentation
- Mise à l’échelle de la sécurité
- Security by design
- Séparation et protection des données
- Backup et Disaster Recovery
- Audit, correctif et adaptation
- Mise à l’échelle de l’équipe
- Définition produit
- Spécialisation / Formation (Dev front, Dev back, UX, UI, …)
- Montées en compétences et apprentissage
- Rôles de facilitation et de support
- Documentation et Intégration
etc …
Et comme pour les fractales quelque soit la thématique c’est l’ensemble du processus qui doit être pensé dès le départ pour pouvoir, si besoin, passer à l’échelle facilement.
Lorsqu’on pense directement à mettre tout à l’échelle on structure les choses différemment. On conçoit en pensant aux autres, à ceux qui vont venir sur le projet éventuellement plus tard ou à ceux qui vont l’utiliser ailleurs.
C’est comme pour l’écriture de logiciel opensource, il est indispensable de l’écrire en pensant aux autres. En facilitant l’intégration, la possibilité de développer sur n’importe quel environnement et de déployer sur n’importe quel plateforme.
Et comme pour l’opensource, la sécurité doit être pensée dès le début. La documentation aussi.
Quel est le coût de d’inclure directement la méta-conception?
C’est un coût très relatif, en effet il ne faut pas directement avoir une solution complète distribuable dans le cloud et fonctionnelle dans tous les environnements possibles. Mais il faut savoir facilement l’adapter.
Concevoir petit à petit et atteindre une position d’équilibre à chaque itération est très important.
Je parle d’itération pas de sprint en effet qu’importe le choix des méthodes de travail il faut accepter d’avancer par petit pas et de découper toujours et systématiquement chaque élément en petite entité concevable en maximum 1 jour.
On écrit, si on arrive à rien en 8h, on jette et on recommence le lendemain en redécoupant encore la tache si nécessaire. L’avantage de cette technique est de permettre de ne pas repartir de rien mais d’avoir eu la nuit pour synthétiser, améliorer de manière passive notre conception de l’idée pour pouvoir ensuite la mettre en pratique d’une autre manière.
La méta-conception c’est simplement parfois le fait d’y penser.
Exemple: On souhaite accéder à une base de donnée pour afficher des articles avec images et vidéo. On part d'une page blanche dont on mesure la vitesse de rendu, on test l'affichage d'un titre, d'une image et d'un texte, on hard-code le texte et l'image et ensuite on écrit le test suivant qui vérifie que le texte et l'image change et on avance ainsi petit à petit.
Avec en permanence la vitesse de rendu affichée à chaque étape, chaque itération, chaque jour, dès que quelque chose ne fonctionne plus ou dès que la vitesse de rendu est trop longue, on jette et on fait évolue la méta-conception liée à ça.
Également chaque question posée par les collègues, chaque remarque du management, d’un designer ou d’un quidam est une opportunité pour documenter, automatiser, remettre en question et atteindre un meilleur niveau, compréhensible de tous et accepter par tous.
C’est une philosophie à mettre en place. Pour la mettre en place il faut impérativement identifier des team lead qui eux même sont convaincu.
On se rend compte du coût de la meta-conception. Il s’agit principalement d’une charge mentale partagée sur l’ensemble de l’équipe. Et qui nécessite des développeurs expérimentés et ayant déjà été confronté à des situations complexes et qui en plus sont capable d’emmener les autres développeurs avec eux.
Ce n’est donc pas un coût négligeable mais c’est un investissement indispensable.
Exemple: pour accéder à un article contenant image et vidéo le développeur fait une jointure entre 3 tables: articles, images et vidéos. Il crée l'article en mémoire et ensuite l'intègre dans une page et fait le rendu. Le team lead test et se rend compte que la query sera exécutée à chaque affichage, il va donc demander au développeur comment il souhaite optimiser celà et si tout va bien un micro service sera créé avec une durée de cache bien déterminée et un système CDN sera mis en place avec une possibilité d'effacer l'ensemble des cache de manière facile pour les équipes qui conçoivent les articles.
Dans tous les cas tout le monde doit comprendre le business, le besoin final, qui est l’utilisateur et ce qu’il attend. Dans tous les cas c’est l’ensemble de la chaîne qui doit être analysé pas juste la partie dont le développeur s’occupe à ce moment là.
Le développeur ne doit pas afficher un article sur un site: il doit faire vivre la meilleur expérience possible à un utilisateur du site tout en tenant compte du coût total du travail qu’il réalise pour l’optimiser au mieux et éventuellement aller plus loin et offrir d’autres débouchés.