Développement spécifique ou solution sur étagère?

Voilà une bonne vieille question que tous les DSI se poseront un jour ou l’autre: l’entreprise veut lancer un projet d’envergure dans des délais très réduits et la question se pose d’acheter une solution sur étagère ou de faire le développement soit-même.

La question en est presque religieuse tellement les avis divergent et sans vraiment de fondement bien établi:

  • On a les partisans de l’achat sur étagère. Souvent ceux qui se sont le plus éloignés de la technique qui choisissent ce genre de solution pour s'épargner les problèmes avec l'IT, parceque on a toujours la sensation que ça va plus vite d'acheter du sur étagère que de le faire soit même ou encore ceux qui vont faire porter le risque de retard sur l'intégrateur ce qui lui permet de dégager sa responsabilité (plus ou moins)
  • On a les partisans du développement spécifique. Souvent ceux qui sont le plus proche du développement: ils ne veulent pas se retrouver enfermer dans une solution +/- ouverte, traumatisme de projets passés, volonté de tout contrôler, etc.

Ces deux populations vont avoir des objectifs différents du fait de leur positionnement

  • Les partisans du "sur étagère" veulent:
    • Se simplifier la vie en ayant la possibilité de tout personnaliser comme ils le souhaitent
    • Éviter des problèmes de performances liés a une mauvaise implémentation et/ou une abstraction trop grande (ce qui peut être un tord)
    • Ne pas être dépendant d’une roadmap tierce
  • Ceux qui vont se poser la question du spécifique ont comme objectif:
    • De garantir le succès
    • De garder le budget
    • D’arriver le plus vite possible à une destination (qui peut être une mise en ligne, l’ouverture d’un outils, etc.)

Les deux solutions sont possibles en réalité mais ces décisions doivent répondre a des critères cohérents et pragmatiques et non pas à des peurs pas toujours rationnelles.

Plutôt que de rester sur ces débats de chapelle, il y a des méthodes qui existent et qui répondent à ces questions: Le Domain Driven Design en fait parti. Surtout: arrêter de croire qu’il y a une réponse parfaite. Ce n’est pas le cas, c’est à adapter à chaque entreprise, chaque contexte. En très résumé, le DDD préconise de déterminer les domaines qui composent la solution.

Et surtout le plus important: déterminer ce qui est cœur de métier pour l’entreprise. Ce qui est cœur doit être le plus protégé: sans dépendance sur l’extérieur (pour ne pas perdre en vitesse de développement, pour ne pas être dépendant d'un tiers, pour rester réactif), maîtriser par des salariés de l’entreprise. Donc: du spécifique.

En revanche tout ce qui est périphérique étant secondaire peut-être externalisé.

Par exemple, mon expérience chez 24 Sèvres, selon cette façon de penser:

  • Le cœur du moteur (le site de eCommerce) est en interne / spécifique car cœur de métier
  • Toutes les technologies secondaires (moteur de recherche, gestion de produit, stock, etc.) sont externalisés dans des solutions spécifiques

Avoir ce type d'approche peu apporter plusieurs avantages:

  • Apporter du pragmatisme dans la décision avec une véritable argumentation des choix technologiques réalisés
  • Ne pas se retrouver dans un cas avec du full-spécifique et une quantité de maintenance qui augmente tellement vite qu'elle en devient intérable
  • Ne pas se retrouver pieds et mains liées avec un éditeur logiciel qui en profite pour pratiquer des tarifs hors du marché