Quand ma fille de 10 ans m’enseigne la conception logicielle

Un de ces matins ou je prépare les enfants pour partir à l’école, ma fille me lance un défi à 8h pour 9h: “Maman, peux-tu me faire des tresses collées ? Mes copines et moi, on s’est mises d’accord pour en avoir toutes aujourd’hui!”

Comme toute bonne cheffe de projet, j’évalue rapidement la faisabilité: “Combien en veux-tu?” — “Deux, ça devrait aller avec le temps qu’on a.”

Nous préparons nos accessoires (parce qu’il en faut beaucoup) : peigne, brosse, élastiques, huile (au passage, l’huile de nigelle est topissime pour les cheveux) etc… Tout semble sous contrôle, ma fille m’arrête: “Attends maman, je vais chercher des élastiques supplémentaires (vous savez les tous fins qu’on met au bout des tresses là?) pour les doubler. Ces élastiques là se cassent souvent et mes tresses lâchent.”

Entre urgence et réalisme :

“Je peux avoir des tresses collées pour 9h” -voilà un cahier des charges classiques ! Un besoin clair, une contrainte temporelle forte, et des utilisateurs finaux (les copines) qui attendent un résultat.

Comme dans nos projets digitaux, la première étape consiste à calibrer les attentes avec les contraintes. Deux tresses au lieu de quatre? C’est exactement ce que nous faisons quand nous proposons un MVP (Minimum Viable Product) plutôt qu’une solution complète : livrer quelque chose de fonctionnel dans les temps impartis.

L’importance de l’environnement technique :

Peigne, élastique, huile… Chaque outil a son rôle, comme notre stack technique. Le peigne me permet de donner une structure (notre Framework), la brosse pour le design final (librairie de styles), l’huile pour la facilité de prise en main, le gel pour la tenue (sécurité), les élastiques pour maintenir (les API, les connexions).

Cette phase de préparation est souvent sous-estimée, alors qu’elle est cruciale. Nous avons souvent commencé à développer notre solution, pour plus tard se rendre compte qu’il nous manquait une dépendance, que tel ou tel environnement n’a pas été configuré comme il le fallait etc…

Quand l’utilisateur devient expert :

La révélation a Poppée dans ma tête quand ma fille propose de doubler les élastiques. Elle ne fait pas que me demander une fonctionnalité supplémentaire: elle identifie un point de défaillance récurrent et propose une solution de redondance.

C’est exactement ce qui se passe avec nos utilisateurs expérimentés. Ils connaissent leurs usages, leurs contraintes, et surtout… leurs points de douleur. Ne jamais sous-estimer les points de douleur d’un utilisateur. “Ces élastiques se cassent souvent” équivaut à “cette API tombe régulièrement” ou “cette fonctionnalité plante sous charge”.

Concevoir pour la durabilité :

La proposition de ma fille révèle une compréhension intuitive de la fiabilité système. Doubler les élastiques c’est penser à tester des composants, des fonctionnalités. Agir avant que le problème ne survienne. Penser que, si un élastique lâche, l’autre maintient la structure, un peu comme la redondance.

Dans nos applications, cela peut se traduire par exemple par la gestion des erreurs robuste, des stratégies de déploiement progressif ( que je n’ai pas encore mis en place personnellement dans mon projet).

La maintenance en conditions réelles :

“Mes tresses lâchent” — cette phrase résume bien l’écart entre l’environnement de développement et la production. En développement, tout fonctionne ( ça ne vous rappelle pas quelque chose quand vous testez en local, tout fonctionne parfaitement, et dès que ça part en production, tout part en vrille?). Les utilisateurs bougent, jouent, courent et des fois taquinent un peu l’application dans des conditions que nous n’avions pas anticipées.

Les tresses de ma fille doivent résister à une journée d’école : récréation, sport, manipulations… Nos applications doivent supporter des pics de charge, des connexions intermittente, des saisies inattendues (injections SQL par exemple), des utilisateurs impatients.

Les leçons d’architecture de ma fille :

Prévoir la redondance dès la conception: Il est plus facile d’ajouter un élastique de renfort au début que de refaire la tresse quand elle lâche. Penser maintenance dès le développement: une application qui fonctionne ne suffit pas, elle doit fonctionner dans la durée. La simplicité apparente cache souvent une complexité réelle: deux tresses semblent simples, mais tenir une journée d’école demande une petite ingénierie subtile.

Article écrit par une maman et conceptrice d’applications qui apprend encore tous les jours…. parfois grâce à sa fille de 10 ans.