Développer ou télécharger une fonctionnalité, le dilemme du code tiers

Les informaticiens détestent réinventer la roue (surtout lorsque c’est eux qui l’ont développé ou que la fonctionnalité déjà existante semble vraiment belle). Les clients et les utilisateurs finaux, de leur côté, détestent devoir payer pour des choses apparemment standards, des mises à jour et des résolutions de bugs. Avec les immenses ressources dont regorgent le web et face aux exigences imposées (temps / budget / et la qualité ?), les codes tiers semblent alors très très tentants.

difficile de maintenir du code tiers
Ce n’est pas mon code et je n’aimerai pas devoir le débugger.

Exemple : Ces 2 derniers semaines, j’ai été particulièrement déçu. Les préconisations SEO principales que j’avais formulées liées à l’architecture d’un site ecommerce ont toutes été retoquées : le site, fonctionnant sous Magento, et habillé par un très joli thème premium se révèle difficile à faire évoluer par l’agence web en charge du projet. Les coûts d’intégration proposés sont suffisamment dissuasifs pour que le client refuse l’implémentation des précos. Rageant et vraiment dommage.

C’est quoi un code tiers ?

  • Un code source acheté (auprès d’un prestataire ou d’un revendeur)
  • Un code source téléchargé tel quel (code open source ou trouvé sur le web)
  • Un code suffisamment étranger pour qu’en interne on ne le comprenne pas (un ancien collaborateur qui était seul à maîtriser une techno par exemple)

Tous les codes tiers ne se valent pas : entre le projet très bien ficelé, maintenu, internationalisé et avec une roadmap claire et le bout de code copié-collé vite fait, les risques ne sont pas les mêmes. Ainsi WordPress ou Drupal sont des codes tiers particulièrement robustes. Ce n’est pas le cas de la majorité des thèmes et extensions que l’on trouve sur ces deux CMS.

Avantages des codes tiers

Plutôt que de devoir re-développer quelque chose pourquoi ne pas regarder si une fonctionnalité similaire existe déjà ? Les bénéfices à court-terme sont évident :

  • Gain de temps
  • Gain d’argent
  • Satisfaction client

À long terme, si le code tiers est solide, les avantages sont indubitables :

  • Meilleure productivité
  • Retour sur investissement plus rapide

Contraintes des codes tiers

C’est surtout dans le temps que les codes tiers montrent leurs faiblesses :

  • Impossibilité de surcharger la fonctionnalité avec du code sur mesure
  • Montée de version impossible (code tiers non maintenu)
  • Montée de version pénible (code tiers évoluant d’une façon non intéressante pour le projet)
  • Support impossible, difficile (lent, cher, inadapté)
  • Incompréhension du mécanisme interne (c’est une boite noire – pourvu que rien ne casse)
  • Difficultés liées à l’internationalisation (pourquoi se lien s’affiche en anglais ?)
  • Tenue dans le temps (et si celui qui est derrière le code tiers arrête ?)
  • Import / export de données
  • Aspects légaux (en cas de problème, qui est responsable ?)
  • Documentation pas forcément claire ni à jour
  • Sécurité, performance et qualité du code
  • Surcharge inutile du projet (code inutile, classes CSS réservées, conflits de version)

Quand utiliser du code tiers ?

Coder ses propres librairies est un exercice important (pour garder la main, pour s’améliorer, pour ne pas devenir flemmard, pour répondre à 100% à la demande du client en terme de fonctionnalité et d’expérience utilisateur, pour contribuer au savoir et à la valeur de l’entreprise…). Cet exercice est d’autant plus nécessaire pour les agences web qui souhaitent se différencier des simples « assembleurs ».

Pour autant, utiliser des codes tiers solides n’est pas choquant. Il convient néanmoins d’en informer le client final. Personnellement, je réutilise mes propres bibliothèques et quelques bibliothèques majeures pour les CMS et le e-commerce mais aussi pour accélérer le développement (jQuery, framework Php, framework Front-End type Bootstrap…).

Je suis, à l’inverse, très méfiant avec tous les plugins qui existent et permettent en théorie de faire plus en moins de temps.

Lorsque la fonctionnalité est accessoire ou facilement interchangeable et que le budget est une contrainte forte, utiliser du code tiers prend tout son sens. Par contre, utiliser un code tiers sur une fonctionnalité majeure est un risque à bien mesurer. Le gain initial n’est-il pas un monstre incontrôlable qui ne manquera pas de se retourner contre celui qui pensait faire « vite fait bien fait » ?

Photo : Niels Heidenreich

Laisser un commentaire

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