La plupart des organisations rencontrent un jour un problème familier : une plateforme existante fait bien des choses de façon acceptable, mais échoue sur le seul flux de travail essentiel à la façon dont l'entreprise fonctionne réellement. Les contournements se multiplient. Le personnel tient des chiffriers parallèles, exporte des données vers d'autres outils ou répète des tâches qui devraient se faire automatiquement.
La réponse tentante est de développer un logiciel sur mesure. Parfois, c'est le bon choix. D'autres fois, le meilleur investissement consiste à configurer un produit existant, à intégrer deux systèmes ou à changer le processus sous-jacent. La décision doit partir des exigences d'exploitation de l'organisation, et non d'une pile technologique préférée.
La décision doit partir des exigences d'exploitation de l'organisation, et non d'une pile technologique préférée.
Constat clé
Il y a généralement quatre choix réalistes
- Conserver et améliorer le système actuel. Réduire la personnalisation inutile, former les utilisateurs, corriger les permissions ou revoir le flux de travail. Ce peut être la voie la plus rapide si le produit prend déjà en charge les fonctions essentielles.
- Acheter un produit configurable. Utiliser une plateforme établie et l'adapter au moyen de paramètres, d'extensions prises en charge et de flux de travail documentés. Parmi les avantages : un déploiement plus court et un entretien assuré par le fournisseur. Parmi les risques : les coûts de licence, un contrôle limité sur les fonctionnalités à venir et un possible enfermement propriétaire.
- Intégrer les systèmes existants. Conserver les meilleurs outils déjà en place, mais créer entre eux un flux d'information fiable. Cette option est attrayante lorsqu'aucun système n'a besoin de tout détenir. L'intégration exige toutefois une propriété claire des données, une gestion des erreurs et une surveillance.
- Développer un logiciel sur mesure. Concevoir une application autour d'exigences d'exploitation et d'intégrations uniques. Le développement sur mesure peut offrir une meilleure adéquation au flux de travail et plus de contrôle, mais l'organisation assume aussi la responsabilité de l'entretien continu, des tests, de l'hébergement, des décisions de sécurité et de la continuité.
Comparez tout le cycle de vie, pas seulement la première facture
Le prix initial de développement ou d'abonnement n'est qu'une partie de la décision. Comparez un coût total de possession sur plusieurs années qui inclut la découverte, la configuration, la migration, les intégrations, la formation des utilisateurs, le soutien technique, la surveillance, les changements futurs, les conditions du contrat avec le fournisseur et le coût des interruptions. Considérez toutes les estimations comme des hypothèses tant qu'elles ne sont pas validées par des propositions.
Le coût d'opportunité d'un flux de travail imparfait compte aussi, mais évitez d'inventer des économies. Partez du temps réel du personnel, des reprises récurrentes, des retards mesurables et des incidents documentés. Une analyse de rentabilité honnête présente une fourchette de résultats plausibles et explique ce qui doit se produire pour que chacun se concrétise.
Les exigences qui devraient orienter votre décision
Avant de choisir une solution, classez les exigences en trois groupes :
- Essentielle : une exigence sans laquelle le processus échoue, une obligation légale ou contractuelle n'est pas respectée ou un utilisateur clé ne peut pas accomplir son travail.
- Importante : une exigence qui réduit les frictions ou améliore la qualité, mais qui peut raisonnablement être mise en œuvre par étapes.
- Facultative : une commodité ou une amélioration qui ne justifie pas une complexité architecturale importante dans la première version.
Documentez ensuite qui utilise le système, quelle information il traite, quelles intégrations sont nécessaires, comment l'accès est contrôlé, quelle indisponibilité est tolérable et comment les données peuvent être exportées si la relation avec un fournisseur prend fin.
Une équipe des opérations peut décrire une fonctionnalité souhaitée comme un tableau de bord. L'exigence sous-jacente pourrait plutôt être une vue quotidienne des actions non résolues avec des responsables désignés. Cette distinction change souvent la conception, le coût et le choix du fournisseur.
Quand le développement sur mesure devient pertinent
Le logiciel sur mesure mérite un examen sérieux lorsque plusieurs des conditions suivantes sont réunies : le flux de travail central est véritablement distinctif; les produits prêts à l'emploi imposent de façon répétée des contournements coûteux; les intégrations sont exceptionnellement complexes; des contrôles d'accès et d'examen propres au domaine sont essentiels; et l'organisation peut assumer la propriété continue de l'application.
Mais la personnalisation n'est pas intrinsèquement plus sûre ni plus évolutive. Les directives sur l'architecture infonuagique insistent sur l'examen explicite de la fiabilité, de la sécurité, des processus d'exploitation et des coûts.[3] Pour les SaaS, AWS souligne aussi l'importance de l'isolation des locataires et d'opérations tenant compte des locataires. Ce sont des responsabilités d'architecture, et non des résultats qui viennent automatiquement avec le code sur mesure.[1][2]
Commencez par un exercice d'exigences modeste
Un bon premier pas consiste à documenter un flux de travail représentatif de bout en bout, une poignée de rôles d'utilisateurs, un ensemble d'exigences priorisées et deux ou trois approches techniques plausibles. Une évaluation indépendante peut déterminer si l'intégration ou la configuration atteindrait le résultat plus économiquement qu'une reconstruction.
Une règle de décision à retenir
Achetez lorsque le besoin est courant et que le produit offert convient. Intégrez lorsque les outils existants fonctionnent mais que l'information ne circule pas entre eux. Développez lorsque les exigences distinctives de l'organisation justifient la propriété d'une solution sur mesure.