Logiciel du marché ou développement spécifique ? Je ne compte plus le nombre de fois où j’ai dû répondre à cette question. Aujourd’hui, elle arrive avec une variante : « Avec l’IA, est-ce qu’on ne pourrait pas le faire nous-mêmes ? »
C’est une vraie possibilité à examiner. Mais je veux comparer un service que l’entreprise pourra utiliser dans la durée, pas seulement deux démonstrations. Le besoin métier, le spécifique à défendre et la capacité de maintenance restent au centre de la décision.
Le make or buy logiciel consiste à décider entre développer une solution et utiliser un logiciel du marché. L’IA modifie cette discussion en facilitant certaines tâches de conception et de développement. Elle permet aussi de tester plus rapidement une idée. La décision doit toutefois couvrir la durée de vie du logiciel, au-delà du premier prototype.
Pour une direction, le bon point de départ est le besoin qui justifie l’investissement. Quelle activité doit progresser ? Quelles règles sont réellement particulières ? Qui assurera le service lorsque les utilisateurs en dépendront ? Ces réponses permettent de comparer des options qui rendent le même service.
Vérifier ce qui doit être spécifique
Un processus inhabituel peut représenter un avantage réel ou seulement une habitude conservée au fil des années. Développer pour reproduire chaque exception peut enfermer l’entreprise dans une organisation coûteuse. À l’inverse, imposer un standard à une activité différenciante peut dégrader le service rendu aux clients.
Il faut examiner quelques cas concrets avec les utilisateurs : l’opération courante, l’exception fréquente et la situation critique. Une démonstration sur ces cas éclaire mieux le choix qu’une longue liste de fonctions cochées dans un tableau.
Quand acheter un logiciel du marché
Une solution du marché peut convenir lorsque le besoin est largement partagé et que l’entreprise accepte ses règles de fonctionnement. L’éditeur prend en charge une partie du développement et de la maintenance du produit. L’entreprise doit encore organiser le paramétrage, les données, les interfaces et l’adoption.
Avant de choisir, vérifiez les limites réellement importantes : possibilités d’intégration, exports, gestion des droits, changements de tarification et conditions de sortie. Une fonction annoncée doit être testée sur vos cas. Les contournements nécessaires peuvent peser autant que l’abonnement dans le coût final.
Quand développer une solution spécifique
Un développement peut se justifier lorsque la fonction est différenciante, que le besoin est compris et qu’aucune option du marché ne répond correctement aux contraintes. La décision suppose une capacité durable de maintenance, en interne ou chez un partenaire. Le responsable métier doit aussi pouvoir arbitrer les évolutions.
L’assistance IA peut accélérer certains travaux, mais elle ne fournit pas à elle seule cette organisation. Le code doit être revu et testé. Les données, les dépendances, les accès et la reprise doivent être maîtrisés. GitHub recommande précisément cette vérification pour le code généré par ses agents.
Comparer aussi une combinaison des deux
Acheter un socle et développer une fonction limitée peut éviter de reconstruire des fonctions standard. Une extension, une interface ou un outil interne peut répondre à un besoin précis. Cette option reste à chiffrer : un petit développement qui devient indispensable devra être exploité et adapté aux évolutions du socle.
Il est utile de préciser les frontières. Quelles données font référence dans le logiciel du marché ? Quelles décisions sont prises dans le composant spécifique ? Que se passe-t-il lorsqu’une interface est indisponible ? Une solution hybride doit rester compréhensible pour ceux qui la feront fonctionner.
Comparer des coûts complets sur le même horizon
Pour chaque option, comptez la mise en œuvre, les données à reprendre, les intégrations, le support, les évolutions et la sortie. Pour le spécifique, ajoutez les tests et la maintenance du code. Pour une solution achetée, incluez le temps de paramétrage et les adaptations nécessaires aux processus.
| Critère | Logiciel du marché | Développement spécifique |
|---|---|---|
| Besoin | Tester le standard et ses limites | Définir les règles qui justifient le spécifique |
| Responsabilité | Organiser paramétrage, données et intégrations | Organiser produit, code, tests et exploitation |
| Coût | Abonnement, adaptation, support et sortie | Construction, hébergement, maintenance et sortie |
| IA | Évaluer les fonctions proposées et leurs limites | Évaluer les gains observés et le travail de vérification |
Comparez ces coûts sur un horizon cohérent avec la décision et examinez plusieurs niveaux d’usage. La capacité d’équipe est une contrainte à part entière. Un développement financièrement séduisant peut retarder un projet plus important s’il mobilise les mêmes personnes.
Un chemin de décision simple
Commencez par vérifier si le besoin reste utile après simplification du processus. Testez ensuite une solution du marché sur les cas clés. Si les écarts sont acceptables, l’achat constitue une option crédible. Si un écart porte sur une fonction différenciante, étudiez une extension limitée. Si le besoin exige un développement plus large, vérifiez d’abord qui pourra le maintenir.
Terminez par une décision écrite qui explique le résultat attendu, les limites acceptées, le responsable du service et les conditions de réexamen. L’IA mérite une place dans cette comparaison, avec des gains observés sur votre périmètre plutôt qu’un pourcentage supposé. Si le choix divise les métiers et la DSI, nous pouvons poser cette comparaison ensemble avant d’engager le projet.
Questions fréquentes
Le SaaS évite-t-il toute maintenance ?
L’éditeur entretient son produit. L’entreprise doit encore gérer ses données, ses paramètres, ses interfaces et les effets des évolutions sur ses processus. Ces activités font partie de la comparaison.
Quand un petit développement IA devient-il un vrai logiciel à maintenir ?
Dès que des utilisateurs dépendent de lui pour une activité régulière, il faut organiser sa responsabilité et son exploitation. La taille du code ne mesure pas son importance opérationnelle.
Pour approfondir
- Comparer les stratégies de choix des outils
- Préparer l’exploitation du logiciel
- Arbitrer un investissement SI
Votre entreprise a grandi plus vite que son SI, ou un choix d’outil bloque la transformation ? Je peux prendre ce sujet avec vous.
Voir mes interventions auprès des dirigeants et DSI
Ping : E-commerce, l'infinie chaine de valeur ou le secret d'Amazon - David LANGLADE