Pourquoi réutiliser l’existant quand on peut réinventer la roue ? Ça fait maintenant 6 ans que je développe pour diverses entreprises, et je n’ai jamais trouvé de réponse à cette question.

Le fait de commencer régulièrement de nouveaux projets signifie visiblement reprendre toute une application depuis le début, quand bien des sites Web, par exemple, ont un certain nombre de points en commun.

J’y vois à première vue trois raisons :

La première tient d’une sorte de « erase and rewind » intellectuel, qui veut que l’on reparte d’un canevas neuf pour chaque nouveau projet. J’ai remarqué ce reflex au sein d’entreprises n’utilisant que peu ou pas de logiciels open source, que ce soit dans leur fonctionnement interne ou comme base de leur développement.

La seconde est purement commerciale, et consiste à justifier les temps de développements cotés au moment de la rédaction du devis. Je ne crois pas qu’elle se justifie dans le cadre d’une prestation en forfait, pour laquelle une application complète est vendue : si le développeur peut travailler plus longtemps, le client est en échange servi moins rapidement, pour un résultat semblable. Dans le cadre d’une prestation en régie, ne pas réinventer la roue permet pour un budget identique d’augmenter les temps de mise en recette et de qualification, assurant par là une application de bien meilleure qualité

La troisième raison est purement technique : ne pas réinventer la roue sous entend soit adapter un existant à un environnement donné, soit accepter de développer des tranches d’applications parfaitement modulaires, et, si possible, interopérables autour d’une API préalablement difficile. Dans le premier cas, la surcharge de travail est difficile à évaluer avant une première utilisation d’un existant donné. Dans le second cas, les délais de développement sont souvent plus longs, le temps de développer un module répondant à un besoin donné : news, faq, carnet d’adresses… tout cela devant être indépendant, et facilement intégrable à la fois.

Dans le cadre d’applications Web, la difficulté ne vient généralement pas de l’application elle-même, mais plutôt du rendu. Doit-on faire une simple sous couche générant les données voulues au moment voulu, un le module doit-il aussi gérer l’affichage au risque de ne pas correspondre avec la charte graphique élaborée à grands frais par le service marketing ? Comme diraient les Shadocks, s’il y a un problème, il y a une solution, et s’il existe une solution, alors il n’y a pas de problèmes. La solution au notre réside dans un markup sémantiquement réfléchi, léger, et laissant l’affichage reposer entièrement sur du CSS. Simple mais terriblement efficace.

Pour résumer ce cours d’énumération d’évidences pourtant pas si évidentes vu ce que j’ai pu rencontrer ces 7 dernières années :

  1. Développez de manière modulaire, c’est plus long la première fois, quasiment instantané la seconde.
  2. Allégez votre markup autant que possible. Pensez à la sémantique.
  3. Laissez CSS faire l’affichage, c’est son boulot, pas celui du XHTML.
Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: