Avant de parler de technologie, de budgets ou de calendriers, une question mérite d'abord une réponse : devons-nous vraiment le construire ? Pourquoi LSR recommande parfois d'acheter un produit, de connecter les systèmes existants ou de corriger le processus.
Lorsqu'une organisation s'adresse à une société de développement logiciel, on s'attend généralement à ce que la discussion débouche sur une proposition de construction : une nouvelle application, le remplacement d'un système vieillissant, une plateforme pour relier des processus déconnectés. L'hypothèse est compréhensible, mais elle esquive une question qui devrait être tranchée avant de parler de technologie, de budgets ou de dates de livraison.
Devons-nous vraiment le construire ?
Chez Libertas Software Research (LSR), nous pensons que savoir s'il faut développer un logiciel compte autant que savoir comment. Parfois, une application sur mesure est exactement ce qu'il faut. Parfois, une plateforme SaaS établie répond parfaitement au besoin, ou connecter les systèmes que vous possédez déjà atteint le résultat sans le coût et la perturbation d'un remplacement. L'objectif est d'améliorer le fonctionnement d'une organisation, pas d'ajouter une application de plus à un environnement déjà compliqué.
Les organisations décrivent volontiers la solution qu'elles pensent nécessaire plutôt que le problème qu'elles rencontrent. « Un tableau de bord de reporting » ou « une application pour remplacer nos tableurs » paraît bien défini, mais cela dit peu de choses sur ce qui a motivé la demande.
Prenons un rapport de gestion mensuel assemblé à la main à partir de plusieurs tableurs et systèmes. Il faut des jours pour le produire, et lorsqu'il arrive, les données sont déjà périmées. La conclusion évidente est qu'il faut un logiciel de reporting. En y regardant de plus près, le vrai problème tient souvent à des données déconnectées et à des processus incohérents : un modeste projet d'intégration, pas une nouvelle application. Et si l'analyse montre que vous avez besoin de workflows ou de contrôles spécialisés qu'aucun produit ne prend en charge, c'est le moment où un développement sur mesure se justifie.
Le marché commercial est mature. CRM, comptabilité, planification, gestion documentaire et business intelligence disposent tous de produits affinés depuis des années. Si l'un d'eux répond à vos besoins sans restrictions déraisonnables, un remplacement sur mesure apporte peu de valeur.
Mais comparez le coût total de possession, pas le prix de l'abonnement. Un produit à 500 £ par mois représente 30 000 £ sur cinq ans, avant d'ajouter la configuration, les intégrations, les licences supplémentaires ou les changements à apporter à vos propres processus. Vérifiez comment la tarification évolue, si vous pouvez exporter vos données et ce qui se passe si l'éditeur change de modèle. Et méfiez-vous de l'idée de forcer l'entreprise à abandonner les activités qui la distinguent vraiment simplement parce qu'un produit part d'une autre hypothèse.
La plupart des organisations accumulent des systèmes au fil du temps : la finance sur l'un, les opérations sur un autre, le service client sur un troisième. Chacun fonctionne bien ; ils ne se parlent simplement pas, ce qui engendre des retards, des doublons et des informations incohérentes.
Tout remplacer par une seule application est tentant, mais risqué. Les plateformes existantes détiennent des années de connaissance opérationnelle et des intégrations cachées. Une couche d'intégration soigneusement conçue (connexion d'API, automatisation des transferts, consolidation du reporting à partir de sources faisant autorité) peut prolonger la vie de ces investissements. Elle exige une réflexion rigoureuse sur l'authentification, la propriété des données, la gestion des erreurs et la traçabilité, mais recommander l'intégration plutôt que le remplacement n'est pas de l'ingénierie au rabais. C'est souvent la décision d'architecture la plus réfléchie.
Certaines exigences ne rentrent vraiment pas dans les produits courants : opérations spécialisées, besoins inhabituels en matière de sécurité ou de données, ou logiciel qui constitue en soi un avantage concurrentiel. Dans ce cas, le logiciel sur mesure permet à l'architecture de suivre la manière dont l'entreprise fonctionne réellement.
Cette souplesse s'accompagne d'une responsabilité à long terme en matière de maintenance, de sécurité, de tests et de support. Un système peut respecter sa spécification d'origine et rester un mauvais investissement s'il est difficile à maintenir ou ne peut pas évoluer. Le développement sur mesure se justifie lorsque les bénéfices d'une solution conçue pour vous l'emportent à la fois sur le coût initial et sur l'engagement permanent d'en être propriétaire.
Parfois, c'est le processus qui pose problème. Les validations, les rapports et les étapes administratives s'accumulent au fil des ans, bien après la disparition des circonstances qui les ont créés. Les automatiser tels quels revient à préserver la complexité.
Si un document nécessite cinq validations, ne demandez pas comment automatiser cinq validations, demandez pourquoi chacune existe et quel risque elle couvre. Le logiciel excelle à appliquer des règles cohérentes, mais il ne peut pas dire si le processus est judicieux. Simplifier un workflow ou clarifier les responsabilités peut apporter de vrais gains sans ajouter un système à apprendre et à supporter.
Les projets sur mesure entraînent un coût initial élevé alors que le SaaS étale le sien sur des abonnements, ce qui rend la comparaison déséquilibrée. Une comparaison équitable couvre toute la durée de vie : mise en œuvre, licences, hébergement, support, maintenance, intégration, formation et évolutions futures.
Incluez aussi le coût de l'inaction. Un processus inefficace qui consomme 20 heures de travail par semaine représente environ 1 040 heures par an. À un taux illustratif de 35 £ de l'heure, cela fait environ 36 400 £ par an, à condition que ce temps puisse réellement être récupéré et réaffecté. Ajoutez la mauvaise qualité des données et la lenteur des décisions, plus difficiles à chiffrer mais tout aussi réelles. La meilleure option n'est pas la moins chère : c'est celle qui offre le meilleur équilibre entre valeur, risque acceptable et pérennité.
La question est légitime. Si nous recommandons un produit ou une petite intégration, cela représente moins de travail de développement sur le papier.
Mais il y a une différence entre fournir de la capacité de développement et agir en partenaire de recherche et d'architecture logicielles. Notre travail commence avant même l'existence du cahier des charges : comprendre le problème, comparer les options et vous aider à décider où investir. Cela a de la valeur quelle que soit l'issue, et il reste généralement des travaux d'analyse, d'architecture, de planification et d'intégration à réaliser même lorsqu'un développement sur mesure n'est pas la réponse.
Recommander un développement dont vous n'avez pas besoin est contre-productif. Un projet livré à temps et conforme à la spécification échoue quand même s'il n'était pas la bonne solution. Aider un client à éviter une dépense inutile construit une confiance durable.
L'IA et les outils modernes rendent le code plus rapide et moins coûteux à produire. C'est utile, mais cela rend la réflexion en amont plus importante, pas moins, car l'effort qui poussait autrefois à se demander « en avons-nous vraiment besoin ? » est en train de disparaître. On peut très bien construire quelque chose de techniquement excellent, le livrer efficacement et découvrir que ce n'était pas la bonne réponse.
Avant le début du développement, nous voulons des réponses claires sur le problème métier, le coût de son maintien, les exigences que les produits existants ne peuvent pas satisfaire, la manière dont le succès sera mesuré (délai de traitement, exactitude, visibilité, conformité, pas le nombre de fonctionnalités) et la personne qui exploitera et supportera la solution ensuite.
Il y aura des projets où le logiciel sur mesure est clairement le bon choix, d'autres où l'intégration offre un meilleur rapport qualité-prix, et d'autres encore où une plateforme prête à l'emploi fait l'affaire. L'essentiel est que la recommandation découle d'une compréhension de votre organisation, et non d'une idée de ce qu'une société de logiciels veut vendre.
Avant de demander comment construire quelque chose, il vaut la peine d'établir s'il faut le construire.
Libertas Software Research accompagne les organisations pour rechercher, évaluer, concevoir et développer des solutions logicielles, en privilégiant la maintenabilité à long terme, la valeur opérationnelle et des investissements technologiques éclairés.