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 navire, 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 Agilap. 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 Agilap 🌠 ! 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 à Agilap, 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. Mailjet 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 ?…😉

le spécifique VS l’intégration

On vous voit venir : « Mais pourquoi ne pas faire que des briques sur mesure et qui correspondent pile-poil à ce que je veux ? ». Il y a plusieurs raisons. Tout d’abord, il s’agit d’une question de budget. Nous serions ravis de vous faire un projet où nous réinventons l’eau chaude mais cela risque de vous coûter un peu (sic) plus cher…

Ensuite, l’intelligence collective a toujours été plus efficace, et c’est aussi le cas dans le code. Même un excellent développeur ne connaitra jamais tous les problèmes que peut poser quelque chose d’aussi simple que l’authentification des utilisateurs. C’est pourquoi il est important de capitaliser sur l’intelligence collective.

Le code, c’est une affaire d’artiste : chacun a son style. Aller demander à un développeur de faire évoluer une application entièrement codée en spécifique, c’est forcer quelqu’un à lire des milliers de lignes de code dans un style qui n’est pas le sien. Et ça, on vous promet qu’aucun développeur n’en a envie…

Enfin, un code spécifique est écrit à un moment donné et marche donc… à un moment donné. Si une correction, un changement, survient dans le langage utilisé, ce n’est pas sûr que le code fonctionnera toujours. L’avantage d’une librairie open source (autrement dit une « brique Lego » disponible et ouverte à tous) de qualité est qu’elle sera régulièrement mise à jour.

Faire du spécifique, du « sur-mesure », a quelque chose d’attirant au premier abord parce que tout est possible. C’est aussi flatteur car cela reconnaît la spécificité du business du client. Mais notre approche est de dire : on va isoler avec vous ce qui fait votre spécificité mais pour le reste, on ne va pas réinventer La Poste. Dans la réalité, pour créer son entreprise, on ne créé pas sa centrale électrique, on fait confiance à des gens (EDF ou autres), qui font ça très bien.

C’est notre philosophie pour vous accompagner tout au long de votre projet !

Bons projets et à bientôt, l’équipe d’Agilap 🌈

Categories: ProjetTechno

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Related Posts

Projet

Choisir la meilleure stack technique 

Vous avez certainement déjà entendu le mot « stack » 📣, par exemple, « stack technique », ingénieur-développeur « full-stack », « stackoverflow »… ça parait tellement évident que l’on oublie souvent d’expliquer les enjeux qui se cachent derrière ce concept.   C’est Read more…

Projet

How I met your project ?

Une première rencontre avec son conseiller digital, c’est un peu comme un premier rendez-vous galant 💘 : on a une multitude d’interrogations et une petite montée de stress avant le dit rendez-vous. Que dois-je amener ? De Read more…

Projet

C’est quoi le développement web durable ?

« Euh, ça ne marche plus ! » 😡. Petite phrase simple à laquelle a déjà été confronté n’importe quel utilisateur du web. Ce qui peut se traduire chez un client par : « Euh, mon site ne fonctionne plus du Read more…