Assis au milieu d’un parterre de Legos, ma nièce de 3 ans me demande « Tonton, construis moi un bateau ». Là où ses parents auraient aligné quelques plaques bleues pour la mer et entassé artistiquement les briques qu’ils ont sous la main pour le bateau, je ne peux pas m’empêcher de demander : « mais ton bateau, tu le veux pour quoi ? Il doit emporter combien de passagers ? Et tu vas vouloir y ajouter des moteurs, un restaurant ou une piste d’hélicoptère ensuite ? »
Déformation professionnelle oblige, je dois connaître les besoins du client… ou de ma nièce avant de me lancer dans un projet. Et finalement, je me dis que développeur c’est un peu comme constructeur de Legos professionnel 💪…
Avant tout, il faut comprendre ce que veut le client, l’accompagner sur ses questionnements, c’est notre côté cabinet de conseil, et enfin faire nos choix d’architecture du projet en fonction 🎯. Tout ça doit permettre à notre client qu’il ne se retrouve pas au final avec un paquebot (Titanic ?) alors qu’il voulait un voilier.
Ensuite vient le temps de création même. Si on continue sur l’exemple des Legos, il va s’agir de choisir les bonnes briques, voire de les fabriquer si elles n’existent pas encore, et de les relier entre elles pour avoir une construction finale solide et qui corresponde au besoin du client.
Trouver le bon Lego
Trouver le bon Lego, c’est trouver le Lego dont la zone d’action n’est ni trop petite, ni trop grande. Si le « Lego » est trop large, il va introduire plein de notions qui ne nous servent à rien et vont alourdir le projet. Si la brique est trop petite, on sera obligés d’aller chercher d’autres Legos pour compléter et il faudra bien les rattacher pour que ça ne fragilise pas notre construction.
Dans le meilleur des cas, le Lego qu’il nous faut existe déjà ou nous l’avons déjà fabriqué chez Levanna. Maintenant, il nous faut décider si on en a besoin à l’intérieur même du projet ou s’il suffit de l’y connecter. Par exemple, l’envoi de mails en grande quantité va se faire via des plateformes externes (Mailjet ou Mailchimp sont connues et reconnues) alors que la gestion des clients va être directement intégrée dans le projet.
Plus compliqué : le cas où la brique n’existe pas, ou pas comme on la souhaiterait 🚫. Il s’agit souvent là du moment où on s’approche vraiment du cœur métier du client. Toute notre approche est construite là-dessus : bien aider le client à différencier ce qui dans son métier est « général » et déjà utilisé par d’autres, et ce qui est vraiment spécifique.
Pour donner un exemple dans la vie de tous les jours, un coiffeur va passer par La Poste pour envoyer et recevoir son courrier (il ne va pas recréer tout un système de coursier juste pour lui !) mais va peut-être créer lui-même les mélanges pour les colorations qu’il propose à ses clients. C’est pareil dans l’informatique. A nous de discuter avec le client pour comprendre son métier et définir les briques générales et celles qu’on va fabriquer juste pour lui.
Des projets évolutifs et durables
« Mais tonton, je voulais une cheminée sur le bateau ! » Ah, l’évolutif… Ma nièce n’en a peut-être pas conscience mais elle touche là au cœur de notre philosophie chez Levanna 🌠 ! Notre but n’est pas de délivrer un projet au client et de ne plus jamais en entendre parler. Tous nos projets sont construits sur ce principe : il faut qu’ils puissent évoluer au cours du temps et en fonction des besoins du client.
C’est pour cela que l’on va toujours privilégier les bonnes pratiques de développement, même si elles peuvent être un petit peu plus lourdes. Soit il ne se passe rien mais on a fait du très bon boulot dont on est satisfait, soit le projet évolue et on a tout prévu pour le faire plus vite, plus facilement, et plus sereinement. Dans tous les cas, on est gagnant.
Et c’est ainsi que je peux ajouter la cheminée au bateau de ma nièce sans avoir besoin de reconstruire un bateau de A à Z.
Et si on devenait nous même une brique ?
Bon, le bateau est enfin construit. Il est beau, il est costaud et ma nièce et ravie. Mais pourquoi le projet de ma cliente nièce ne deviendrait-il pas lui-même utilisable par d’autre ? Quelqu’un qui, par exemple, voudrait une flotte de bateau et qu’il aurait justement besoin du modèle de celui de ma nièce.
Si on revient à Levanna, cela veut dire que nous créons tous nos projets de manière à ce qu’ils puissent eux-mêmes devenir des briques intégrables. En effet, si le service du client est accessible facilement par d’autres, cela peut générer une source de trafic, de clients ou de business pour le client. Docs-Dispatcher par exemple n’est pas « open source » (son code n’est pas accessible) mais c’est parce qu’il a été créé comme ça qu’énormément de clients et de développeurs utilisent ses services.
« Et maintenant, je veux que tu me fasses un mouton ». Et si je te disais que je te fabrique un bateau et que le mouton est dedans ?…😉
