Développement Logiciel D'entreprise : Ce Que Vous Achetez

Le développement logiciel d’entreprise, tel que l’expression est employée sur la plupart des sites d’agences, désigne le même travail avec un chiffre plus élevé à côté. L’équipe est la même, le processus est le même, la présentation gagne un mur de logos, et le prix triple. Les acheteurs le savent, et les services achats ont appris à ignorer le mot pour lire les annexes.

Il existe pourtant une vraie distinction en dessous, et elle ne tient pas à la taille de l’entreprise. Un assureur de quarante personnes peut mener un programme réellement d’entreprise, et un distributeur de douze mille personnes peut commander ce qui n’est en fait qu’un site web. Ce qui les sépare, ce sont les obligations que le système impose à celui qui le construit : combien d’autres systèmes il doit interroger, combien de temps il peut rester indisponible, qui peut opposer son veto à une mise en production, quel régulateur s’y intéresse, et ce qui arrive si le fournisseur s’en va.

Ce qui suit définit la catégorie par ces obligations, pour qu’un acheteur distingue un fournisseur capable de les porter de celui qui vend un projet ordinaire sous une couverture d’entreprise.

Qu’est-ce qui rend un projet logiciel réellement d’entreprise ? Pas la taille de l’acheteur. Un projet est d’entreprise quand il porte des contraintes qu’un projet ordinaire n’a pas : une large surface d’intégration, une obligation contractuelle de disponibilité et de reprise, une exposition réglementaire, plusieurs groupes de parties prenantes capables chacun de bloquer une livraison, des volumes de données qui cassent les conceptions naïves, et l’obligation de coexister avec des systèmes que personne ne comprend. Ce sont ces contraintes, et non la liste de fonctionnalités, qui décident de l’architecture et de l’essentiel du coût.

Ce qui rend un projet d’entreprise

Le test utile est une liste de contraintes, et un projet se qualifie quand il en porte la plupart plutôt qu’une seule. Appliqué honnêtement, il disqualifie une grande part de ce qui est vendu comme projet d’entreprise, et qualifie des travaux vendus comme petits projets qui échouent ensuite parce qu’ils ont été cadrés ainsi.

La surface d’intégration

Comptez les systèmes avec lesquels votre nouveau logiciel doit échanger des données, puis comptez le nombre d’équipes ou de fournisseurs distincts qui possèdent ces systèmes. C’est le second chiffre qui prédit le coût. Trois intégrations détenues par une seule équipe interne représentent quinze jours de travail. Trois intégrations détenues par trois fournisseurs, chacun avec sa fenêtre de changement, sa disponibilité de bac à sable et son support, représentent un trimestre.

Chaque propriétaire apporte un calendrier que vous ne contrôlez pas. Un fournisseur dont le bac à sable se rafraîchit tous les mois fixe votre rythme de test, et un prestataire de paiement dont la certification prend six semaines fixe votre date de mise en service. Avec une douzaine de contreparties, le calendrier d’intégration devient le plan de projet, et le développement se glisse dans les creux.

L’obligation de disponibilité

D’un logiciel ordinaire, on attend qu’il fonctionne. Un logiciel d’entreprise a un chiffre attaché à cette attente, en général dans un contrat avec un avoir derrière. Ce chiffre change d’abord l’architecture, car un déploiement sur une seule instance ne peut pas l’honorer, quelle que soit la qualité du code.

Le passage d’un objectif qui tolère une fenêtre de maintenance à un objectif qui n’en tolère aucune est la ligne la plus chère de la plupart des budgets d’entreprise, et elle est souvent validée par des gens qui n’en ont jamais vu le prix. Notre article sur les SLA de disponibilité qui veulent dire quelque chose explique comment ces chiffres s’écrivent et à quel point ils s’écrivent mal.

Des parties prenantes avec droit de veto

Un projet ordinaire a un responsable produit. Un projet d’entreprise a un responsable produit, une fonction sécurité de l’information, un délégué à la protection des données, un responsable achats, une équipe infrastructure qui possède le réseau, un centre de services qui héritera de la charge de support, et souvent un relecteur clinique, juridique ou conformité.

Chacun d’eux peut arrêter une livraison, et aucun ne dépend de la personne qui paie le travail. Les décisions prennent donc un temps calendaire sans rapport avec leur difficulté, et un fournisseur qui n’a pas prévu cela rate toutes les échéances dès le deuxième mois.

Les systèmes que plus personne ne comprend

Tout parc applicatif d’entreprise contient au moins un système dont le comportement n’est documenté que par sa sortie. Ceux qui l’ont écrit sont partis, et la spécification, si elle existe, décrit une version antérieure. Il fonctionne, il est porteur, et le modifier passe pour imprudent.

Le nouveau logiciel doit coexister avec lui, donc quelqu’un doit d’abord établir ce qu’il fait réellement. C’est de l’archéologie, pas du développement : lire les données de production, tracer les appels, mener des expériences contrôlées sur une copie, et écrire les règles que le code implique. Sur un grand parc, cela représente des semaines de travail, et c’est le poste le plus souvent supprimé pendant la négociation parce qu’il ne produit aucune fonctionnalité visible.

Le supprimer déplace le travail vers les tests d’intégration, où il est découvert sous pression par des gens qui corrigent déjà des anomalies. Un fournisseur qui chiffre la découverte séparément et la défend vous dit quelque chose de vrai sur la façon dont ces programmes échouent. Notre note sur la modernisation du legacy et le choix entre réécriture et refactorisation décrit ce que cette archéologie trouve.

Les achats représentent la moitié du travail

La plupart des techniciens sous-estiment cette partie d’un facteur trois. Sur un engagement réellement d’entreprise, le travail entre la première conversation et la première ligne de code dure plus longtemps que le premier incrément de livraison, et il consomme du temps de dirigeants des deux côtés.

Depuis le 24 février 2025, le secteur public britannique fonctionne sous le Procurement Act 2023, et les fournisseurs qui répondent à des marchés publics doivent être inscrits sur la plateforme numérique centrale au sein du service Find a Tender élargi. Les achats privés n’ont pas de porte d’entrée unique équivalente, ce qui les rend paradoxalement plus lents, car chaque acheteur a inventé la sienne.

Le questionnaire de sécurité

On vous enverra un tableur. Il portera sur votre cycle de développement, vos contrôles d’accès, votre cadence de correctifs, vos sous-traitants, la résidence de vos données, vos délais de réponse aux incidents et vos vérifications d’antécédents. Les gros acheteurs envoient plusieurs centaines de questions, et une banque ou un établissement du NHS en envoie davantage.

Les questions ne sont pas difficiles, mais elles ne trouvent réponse que si les réponses existent déjà sous forme de politique. Un fournisseur qui les assemble pour la première fois pendant un appel d’offres met quatre à six semaines et se trompe sur plusieurs. Celui qui l’a déjà fait répond en quelques jours depuis une bibliothèque de réponses entretenue, ce qui est une raison légitime de le préférer.

Référencement fournisseur, assurances et vérifications financières

Le référencement est distinct de l’appel d’offres et se déroule souvent en parallèle. Attendez-vous à prouver une responsabilité civile professionnelle et une assurance cyber au niveau que l’acheteur précise, une assurance responsabilité employeur, et parfois une responsabilité produit. Les acheteurs d’entreprise exigent couramment des plafonds qu’un petit cabinet ne porte pas par défaut, et relever une couverture en cours d’appel d’offres prend du temps.

Viennent ensuite les vérifications financières. Les acheteurs consultent les comptes déposés, demandent une notation de crédit et, sur les gros contrats, réclament des situations comptables ou une garantie de la société mère. Un fournisseur dont le bilan ne supporte pas la valeur du contrat est écarté quel que soit son mérite technique, et c’est ainsi que de petites structures compétentes perdent des marchés qui leur convenaient.

Pourquoi le cycle de vente dure plus longtemps que le premier incrément

Mettez les deux calendriers côte à côte et la forme du problème apparaît. Qualification, exigences, revue de sécurité, négociation juridique, preuves d’assurance et référencement occupent couramment quatre à neuf mois sur un contrat de plusieurs centaines de milliers de livres. Le premier incrément logiciel utile, une fois le travail lancé, peut prendre dix semaines.

Les estimations écrites au début de ce cycle sont périmées à la signature, et un fournisseur qui tient un prix ferme sur tout l’intervalle gonfle largement ou compte discuter du périmètre plus tard. Les hypothèses technologiques vieillissent aussi, et une version à jour au moment de l’offre peut être hors support au lancement.

Datez chaque estimation, énoncez ses hypothèses, et convenez d’une remise à plat à la signature plutôt que de prétendre que le chiffre a survécu. Les acheteurs qui exigent que le montant initial tienne achètent une file de demandes de changement. Notre guide pour rédiger un cahier des charges logiciel qui obtient des devis utiles décrit ce qui doit figurer dans le document.

Les exigences non fonctionnelles sont le vrai livrable

Les listes de fonctionnalités sont faciles à écrire et ne décident presque rien. Les exigences non fonctionnelles décident de l’architecture, de la facture d’infrastructure, de la taille de l’équipe et de la durée du cycle de test, et dans la plupart des programmes d’entreprise elles tiennent en deux paragraphes dans un document dont la liste de fonctionnalités fait quarante pages.

Ce déséquilibre est le meilleur indicateur d’un dépassement. Un fournisseur qui consacre le premier atelier à la disponibilité, à la reprise, à la latence, au débit, à l’auditabilité et à la conservation ne temporise pas : ces six chiffres éliminent la plupart des options d’architecture, et les fixer tard oblige à reconstruire.

Écrivez-les comme des énoncés testables portant un chiffre et une condition. Le système doit être hautement disponible n’est pas une exigence. Le service de commandes doit tenir une disponibilité mensuelle de 99,9 pour cent mesurée au répartiteur de charge, hors fenêtre de deux heures annoncée cinq jours ouvrés à l’avance : cela en est une, parce qu’un test peut la faire échouer.

Point de reprise et temps de reprise en clair

Deux de ces chiffres pèsent plus sur le coût que n’importe quelle fonctionnalité, et ils sont couramment cités par des gens qui en ont interverti le sens. L’objectif de point de reprise est la quantité de données que vous acceptez de perdre : un RPO d’une heure signifie que vous acceptez que jusqu’à une heure de transactions disparaisse après un sinistre, et votre schéma de sauvegarde ou de réplication ne doit pas faire pire. L’objectif de temps de reprise est la durée pendant laquelle vous acceptez d’être arrêté, donc un RTO de quatre heures signifie que le service sert de nouveau du trafic dans les quatre heures suivant le début de l’incident.

Les deux chiffres se traduisent directement en architecture. AWS expose quatre grandes stratégies dans son guide de reprise après sinistre : sauvegarde et restauration, veilleuse, secours tiède, et multi-site actif/actif. Elles vont de bon marché et lent à cher et quasi instantané, et le choix est fait pour vous dès que les deux objectifs sont convenus.

Évitez de convenir de chiffres agressifs parce qu’ils semblent responsables. Un RPO de zéro avec un RTO de quelques minutes impose une réplication continue et un second environnement actif, ce qui double à peu près la facture d’infrastructure. Notre analyse de la reprise après sinistre pour les petites équipes logicielles montre ce qu’achètent les paliers moins chers.

Arithmétique de la disponibilité et ce qu’achète vraiment un SLA

Les pourcentages de disponibilité cachent leur sens derrière une virgule. Sur un mois de 30 jours, 99,9 pour cent autorisent environ 43 minutes d’arrêt, 99,95 pour cent environ 22 minutes, et 99,99 pour cent environ 4 minutes. C’est le budget du mois entier, déploiements, renouvellements de certificats et bascule de base de données plus longue que prévu compris.

Quatre minutes par mois sont hors de portée d’une équipe qui déploie aux heures de bureau et réveille un seul ingénieur. Il faut de la redondance à chaque étage, une bascule automatique, des déploiements qui n’interrompent pas le trafic, et quelqu’un d’éveillé à trois heures du matin. Ce dernier point coûte en général plus cher que l’infrastructure et ne figure presque jamais au budget initial. Fixez aussi le point de mesure dans le contrat, car la disponibilité lue au répartiteur de charge et celle lue depuis la télémétrie réelle des utilisateurs peuvent différer d’un ordre de grandeur sur le même incident.

Latence, débit et la charge que personne n’a mesurée

Les objectifs de latence exigent un centile et un périmètre, car les moyennes dissimulent les échecs. Un objectif annoncé de 200 millisecondes au 95e centile pour le point de terminaison de paiement, sous une charge de 400 requêtes par seconde, est testable. Un objectif de rapidité ne l’est pas, une moyenne non plus, puisqu’une moyenne de 200 millisecondes est compatible avec un utilisateur sur vingt qui attend quatre secondes.

Le débit exige un pic, pas une moyenne. Les distributeurs dimensionnent pour le vendredi avant Noël, les systèmes de paie pour le dernier jour ouvré du mois, et les services publics pour l’échéance figurant dans le courrier envoyé. Dimensionner pour la moyenne annuelle, c’est ainsi qu’un lancement échoue à sa première heure chargée. Prenez le pic dans les journaux du système existant, où les rapports de dix à un sont courants, car ce rapport décide si la conception a besoin d’une file d’attente.

Auditabilité et conservation

Les acheteurs régulés, et de plus en plus les autres, doivent pouvoir répondre des années plus tard à la question de savoir qui a changé quoi et quand. C’est une exigence de conception plutôt qu’un réglage de journalisation : un système qui écrase ses lignes ne peut pas y répondre, et la réponse doit survivre aussi longtemps que la politique de conservation l’indique.

Décidez trois choses tôt. Quels événements sont auditables, en général les changements d’état sur des enregistrements à portée juridique ou financière plutôt que chaque requête HTTP. Combien de temps chaque catégorie d’enregistrement est conservée, question juridique assortie d’une contrainte de protection des données, puisque garder des données personnelles plus longtemps que nécessaire est en soi un manquement. Et qui peut lire la piste, car un journal d’audit que les administrateurs peuvent modifier ne prouve rien. Conservation et droit à l’effacement se heurtent ici, et la tension se règle dans le schéma plutôt que dans la politique.

Les certifications qu’un acheteur demandera

Trois reviennent sans cesse, elles sont constamment confondues, et elles prouvent des choses différentes. Un fournisseur incapable d’expliquer la différence ne les détient pas.

Cyber Essentials et Cyber Essentials Plus

Cyber Essentials est le socle soutenu par le gouvernement britannique, élaboré par le NCSC et délivré via IASME, son partenaire officiel de mise en oeuvre. Il couvre cinq contrôles techniques : pare-feu, configuration sécurisée, gestion des mises à jour de sécurité, contrôle des accès utilisateurs et protection contre les logiciels malveillants. Le niveau de base est un questionnaire d’auto-évaluation revu de façon indépendante, et le NCSC annonce des tarifs à partir de GBP 320 hors taxes selon la taille de l’organisation.

Cyber Essentials Plus reprend les mêmes cinq contrôles, vérifiés par un audit technique indépendant plutôt que déclarés. L’évaluateur mène des analyses de vulnérabilité internes et externes et teste un échantillon de postes utilisateurs, de passerelles internet et de serveurs exposés sur internet. L’audit Plus doit être achevé dans les trois mois suivant la certification de base, et les deux certificats durent douze mois.

Le dispositif compte autant sur le plan commercial que technique. PPN 014, en vigueur depuis le 24 février 2025 dans les ministères, leurs agences, les organismes publics non ministériels et les entités du NHS, impose la certification lorsque les fournisseurs manipulent des données personnelles de citoyens, des données personnelles d’agents publics, ou des systèmes informatiques traitant des données classées OFFICIAL.

ISO/IEC 27001

ISO/IEC 27001 est la norme internationale du système de management de la sécurité de l’information, publiée par l’ISO et la CEI. L’édition en vigueur est ISO/IEC 27001:2022, avec l’amendement 1 de 2024 qui ajoute une formulation sur l’action climatique aux clauses de contexte, conformément à une modification appliquée à toutes les normes de système de management de l’ISO.

C’est une norme de système de management, et c’est cette partie que les acheteurs lisent de travers. Elle ne prescrit pas un jeu fixe de mesures que toute organisation certifiée aurait mises en oeuvre. Elle exige que l’organisation définisse son périmètre, évalue ses risques, sélectionne des mesures, et fasse tourner un cycle documenté de revue et d’amélioration. La certification est délivrée par un organisme accrédité après audit, et non par l’ISO elle-même.

La question utile n’est donc jamais de savoir si un fournisseur la détient, mais ce que couvre la déclaration de périmètre portée par le certificat. Un périmètre limité à une fonction du siège ne vous dit rien sur l’équipe qui détient votre code source et vos accès de production. Demandez le certificat et lisez le périmètre.

SOC 2

SOC 2 est américain et de nature différente. L’AICPA le définit comme un rapport sur les contrôles d’une organisation de services pertinents pour la sécurité, la disponibilité, l’intégrité de traitement, la confidentialité ou la vie privée, réalisé selon ses trust services criteria. C’est un rapport d’attestation produit par un cabinet d’experts-comptables, pas un certificat, et il n’y a ni note de passage ni logo à afficher.

La distinction qui compte est le type. Un rapport de type 1 décrit les contrôles et juge s’ils sont correctement conçus à un instant donné. Un rapport de type 2 teste s’ils ont fonctionné efficacement sur une période, couramment six ou douze mois. Le type 1 est une photographie et le type 2 un film, et les acheteurs qui acceptent un type 1 comme équivalent acceptent bien moins qu’ils ne le pensent.

Lisez le rapport, pas la page de garde. La section des exceptions, où l’auditeur consigne les contrôles qui n’ont pas fonctionné comme décrit, porte l’information, et c’est la partie que les fournisseurs espèrent vous voir sauter.

Ce qu’aucune ne prouve

Aucune des trois ne certifie que votre logiciel est sûr. Cyber Essentials couvre un socle d’hygiène d’infrastructure. ISO 27001 couvre le fait que l’organisation gère la sécurité comme un processus. SOC 2 couvre le fait que des contrôles annoncés ont fonctionné sur une période. Toutes trois concernent le fournisseur, pas le produit.

La sécurité applicative est une discipline distincte avec des preuves distinctes. Demandez le dernier rapport de test d’intrusion et l’état de sa remédiation plutôt que le mur de certificats, et vérifiez qui l’a réalisé et sur quel périmètre. C’est la substance derrière nos services de test d’intrusion.

Exposition réglementaire par secteur

La réglementation est l’endroit où les conseils génériques sur l’entreprise deviennent dangereux. Ce qui suit nomme des obligations vérifiables et s’arrête avant le conseil juridique, que vous devez prendre auprès d’un conseil qualifié.

Le UK GDPR, qui s’applique à presque tout le monde

Si le système touche des données personnelles, l’article 32 du UK GDPR s’applique au responsable de traitement comme au sous-traitant. Il impose des mesures techniques et organisationnelles appropriées, et il en nomme quatre : la pseudonymisation et le chiffrement, la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes de traitement, la capacité à rétablir la disponibilité des données personnelles et l’accès à celles-ci dans des délais appropriés après un incident, et une procédure de test et d’évaluation réguliers de l’efficacité de ces mesures.

Relisez la troisième, car elle fait de la reprise après sinistre une obligation de protection des données plutôt qu’une préférence opérationnelle. Le guide de l’ICO sur la sécurité des données désigne Cyber Essentials comme un socle utile tout en indiquant clairement qu’il ne s’agit que d’un jeu de mesures de base, qui ne couvrira pas la situation de chaque organisation ni les risques de chaque traitement.

Services financiers et santé, brièvement et prudemment

Dans les services financiers, le régime de résilience opérationnelle de la FCA impose aux entreprises concernées d’identifier leurs services métier importants, de fixer des tolérances d’impact pour chacun, et de pouvoir rester dans ces tolérances lors d’une perturbation grave mais plausible. La période de transition s’est achevée le 31 mars 2025, l’obligation est donc active et façonne ce qu’un fournisseur de ces entreprises doit prouver.

Dans la santé et le médico-social, un système informatique de santé relève des normes de gestion du risque clinique de NHS England : DCB0129 pour les fabricants et DCB0160 pour les organisations qui le déploient. Les deux font l’objet d’une revue nationale, avec une consultation publique ouverte du 29 juin 2026 au 11 septembre 2026, vérifiez donc la position actuelle avant de vous fier à un résumé, y compris celui-ci.

Si votre secteur n’est pas nommé ici, traitez l’obligation de façon générique : identifiez le régulateur, lisez ses exigences publiées, et faites prouver le fournisseur contre celles-ci plutôt que contre un discours d’assurance général.

L’architecture d’intégration est là où part l’argent

Le coût d’entreprise se concentre dans les coutures entre systèmes, pas à l’intérieur. Les fonctionnalités sont en général bien comprises. Amener six systèmes aux modèles de données différents et aux notions de client différentes à se mettre d’accord, voilà où passe le calendrier.

Point à point ou courtier de messages

Le point à point est le choix par défaut parce que la première intégration est réellement plus simple ainsi. Le coût est combinatoire : avec n systèmes qui se parlent directement, vous tendez vers n au carré connexions, chacune avec sa logique de reprise, ses identifiants et sa supervision. À quatre systèmes cela va. À quinze ce n’est plus maintenable.

Un courtier ou un bus d’événements inverse cette courbe. Il ajoute un composant, une charge d’exploitation et un point unique de défaillance à concevoir, et il devient rentable vers le sixième ou le huitième participant. L’erreur se commet dans les deux sens : les petits parcs achètent une plateforme d’intégration dont ils n’ont pas besoin, et les grands la repoussent jusqu’à ce que le maillage se soit calcifié.

Synchrone ou piloté par les événements

Un appel synchrone est facile à raisonner et couple la disponibilité. Si votre service appelle quatre systèmes en ligne et que chacun est disponible 99,9 pour cent du temps, votre propre plafond est d’environ 99,6 pour cent avant même d’avoir écrit un bogue. Chaque dépendance synchrone est une part de votre disponibilité confiée à l’équipe d’exploitation de quelqu’un d’autre.

Les conceptions pilotées par les événements découplent cela, au prix d’une cohérence à terme et d’un débogage bien plus difficile. Gardez les appels synchrones pour le chemin où l’utilisateur attend et où une réponse périmée est inacceptable, et basculez tout le reste sur des événements. Décidez cela par interaction plutôt que comme un style maison.

Idempotence, rejeu et rapprochement

Les systèmes distribués livrent les messages plus d’une fois et en perdent parfois, donc tout chemin d’écriture qui franchit une frontière doit pouvoir être répété sans danger. Le motif établi est une clé d’idempotence générée par le client. La mise en oeuvre de Stripe enregistre le code de statut et le corps de la première requête portant une clé donnée, renvoie le même résultat lors des reprises, purge les clés après au moins 24 heures, et signale une erreur si la même clé arrive avec des paramètres différents.

Le rejeu est la moitié opérationnelle de la même idée. Après six heures d’indisponibilité d’un système aval, quelqu’un doit pousser les messages manqués, ce qui n’est sûr que si les consommateurs sont idempotents et que les messages ont été conservés. Concevez la fenêtre de conservation et le mécanisme de rejeu en même temps que le chemin nominal, car les ajouter après coup oblige à modifier chaque consommateur.

Le rapprochement est traité comme une arrière-pensée et ne devrait pas l’être. C’est un traitement planifié qui compare l’état de deux systèmes censés concorder, signale les écarts et soit les corrige, soit les remonte à un humain. Sans lui, une divergence silencieuse avec un système financier est trouvée des mois plus tard par un auditeur. Budgétez-le comme un livrable à part entière, avec un responsable et une route d’alerte, pas comme un script écrit à la fin.

Coexistence avec le legacy et le figuier étrangleur

Le remplacement intégral d’un système qui fonctionne est l’option la plus risquée disponible, et elle est choisie bien plus souvent qu’elle ne devrait l’être. L’alternative incrémentale est documentée par Microsoft sous le nom de motif du figuier étrangleur : placer une façade devant le système existant, y router les requêtes, et déplacer les fonctions une par une jusqu’à ce que l’ancien système n’ait plus de trafic et puisse être éteint.

Chaque incrément a une valeur propre et est réversible séparément : si la troisième tranche tourne mal, vous la renvoyez en arrière. Microsoft est explicite sur les cas où le motif ne s’applique pas, à savoir quand les requêtes vers le back end ne peuvent pas être interceptées, quand vous ne pouvez pas modifier le source existant, ou quand le système est assez petit pour qu’un remplacement direct soit plus simple.

Deux détails décident si cela marche. La façade ne doit devenir ni goulot d’étranglement ni point unique de défaillance, elle réclame donc la même ingénierie de disponibilité que les services derrière elle. Et les appels entre systèmes pendant la transition ont besoin d’une couche anticorruption, pour que la sémantique existante ne fuie pas dans la nouvelle conception. Les données sont plus dures que le trafic : sortir les tables d’un domaine impose un chargement initial, un flux de capture des changements, une période de validation où les deux magasins sont écrits et comparés, et seulement ensuite une bascule, avec retour arrière possible jusqu’à la suppression des objets existants.

Les tests à l’échelle de l’entreprise

Tester sur un programme d’entreprise est autant un problème de logistique que d’ingénierie, et c’est là que meurent les plans optimistes.

Les environnements

Il vous en faudra plus que prévu : le développement, un environnement d’intégration raccordé aux bacs à sable des contreparties, un environnement de performance assez proche de la production pour que ses chiffres veuillent dire quelque chose, un environnement de recette assez stable pour des non-techniciens occupés, et la production. Chacun a un coût d’infrastructure, un processus de rafraîchissement et un responsable. Celui qui glisse toujours est la performance, et le sauter revient à tester la charge en production.

Les données de test et le problème des données personnelles

Les systèmes d’entreprise ont besoin de données réalistes pour être testés, et les données réalistes sont les données de production, qui contiennent des informations personnelles. Les copier dans un environnement de test est un traitement au sens du UK GDPR, et les obligations de l’article 32 les y suivent, y compris le contrôle d’accès et la sécurité de l’environnement qui les héberge.

Les réponses défendables sont l’anonymisation, qui doit être irréversible pour sortir les données du règlement, ou la pseudonymisation, qui réduit le risque mais les y maintient. Les deux réclament un travail d’ingénierie pour préserver la forme statistique qui rend les données utiles, et un processus documenté. Restaurer une base de production dans un environnement de test partagé est courant, illicite dans bien des configurations, et exactement ce qu’une évaluation fournisseur est conçue pour révéler.

Les tests de performance

Les tests de performance répondent à la question de savoir si le système atteint les chiffres de débit et de latence convenus plus tôt, ils ne peuvent donc exister que si ces chiffres ont été écrits. Testez le profil de pic plutôt que la moyenne, et incluez la forme du pic, car une montée sur dix minutes et une marche en une seconde sollicitent des modes de défaillance différents.

Exécutez-les sur des volumes de données de production. Une requête instantanée sur 10 000 lignes et inutilisable sur 40 millions est le défaut de performance le plus courant du logiciel d’entreprise, et il est invisible sur un petit jeu de données.

La recette avec des gens qui ont un autre métier

La recette est planifiée sur une fenêtre de deux semaines et c’est la phase qui déborde le plus sûrement, parce que les testeurs sont les experts métier et que le métier a toujours besoin d’eux. Ils vous donneront quelques heures par semaine, et leur disponibilité s’effondre en fin de mois.

Nommez les testeurs dans le contrat, convenez des heures par semaine, scénarisez les cas à l’avance plutôt que de demander aux gens d’explorer, et menez le tri des anomalies en séance commune plutôt qu’en file de tickets. Un fournisseur qui chiffre deux semaines de recette sans participants nommés n’en a jamais mené.

Modèle de livraison et gouvernance

La forme d’équipe qui marche est petite et stable plutôt que grande et tournante : un responsable technique qui porte l’architecture de tout le programme, trois à six ingénieurs, un responsable de livraison qui tient le calendrier des contreparties, et un accès partagé à un ingénieur qualité et à un spécialiste infrastructure. Ajouter des gens en cours de route ralentit un programme de façon fiable, car la contrainte est le contexte, pas les bras.

Écrivez la propriété des décisions avant le premier sprint. Nommez une personne qui peut approuver les changements de périmètre, une qui peut arbitrer les compromis d’architecture, et une qui peut accepter une livraison. Si ce sont trois noms, les décisions prennent des jours. Si ce sont des comités, elles prennent des semaines et le plan est une fiction.

La cadence de pilotage garde honnête un long programme : revue de livraison toutes les deux semaines avec le groupe de travail, comité mensuel avec le porteur du budget et les détenteurs du veto dans la même pièce, et un état écrit rapporté à la référence initiale plutôt qu’à la version révisée du mois dernier. Un fournisseur dont le statut est vert en permanence ne pilote pas le risque, il le cache.

Modèles commerciaux et qui porte le risque

Quatre modèles couvrent presque tout, et chacun place le risque ailleurs. La question n’est pas lequel est le meilleur mais quelle partie est la mieux placée pour porter l’incertitude qui est devant vous.

La régie convient à un travail réellement incertain : la découverte, l’archéologie du legacy, ou une intégration face à une contrepartie mal documentée. L’acheteur porte le risque et obtient une souplesse totale, ce qui suppose de la confiance et un rythme de consommation que quelqu’un surveille vraiment.

La régie plafonnée ajoute un plafond, et c’est le compromis raisonnable habituel, celui qui structure la plupart de nos services de développement logiciel. Le fournisseur absorbe le dépassement au-dessus du plafond, l’acheteur ne paie en dessous que ce qui est consommé, et les deux côtés gardent le périmètre honnête. Attendez-vous à ce que le plafond porte de quinze à vingt-cinq pour cent de provision, car un fournisseur qui plafonne au coût attendu se trompe ou prépare une demande de changement.

Le forfait ne marche que là où le périmètre est réellement figé, ce qui, sur un programme d’entreprise, vaut pour un incrément et non pour l’ensemble. Des incréments au forfait de six à dix semaines, chacun cadré une fois le précédent livré, donnent de la certitude budgétaire sans prétendre que quiconque peut spécifier dix-huit mois à l’avance.

L’infogérance est la bonne forme une fois le système en service : un forfait mensuel couvrant le support, les correctifs, la supervision et une enveloppe de changement définie, tarifé en pourcentage du coût de construction par an plutôt qu’à l’effectif. Faites nommer par la définition de service les délais de réponse et le chemin d’escalade.

Développement logiciel d’entreprise : ce qui pèse sur le coût

Les facteurs de coût par ordre d’impact

L’ordre surprend, car les fonctionnalités viennent en dernier. La surface d’intégration vient en premier, et précisément le nombre de propriétaires externes plutôt que le nombre de points de terminaison. Les cibles non fonctionnelles viennent en deuxième, car le passage d’un service qui tolère une fenêtre de maintenance à un service qui n’en tolère aucune change chaque couche de la conception.

Troisième vient la charge d’assurance et de réglementation : temps d’offre, production de preuves, appui aux audits et processus de livraison plus lent pendant toute la durée du contrat. Quatrième, la migration de données et le rapprochement, systématiquement sous-estimés parce que la difficulté tient à la qualité des anciennes données plutôt qu’au volume. Cinquième, le nombre de groupes de parties prenantes, qui fixe la latence de décision. Sixième, le nombre d’environnements. Le périmètre fonctionnel est septième, et c’est en général la seule chose au budget initial.

Fourchettes de prix indicatives au Royaume-Uni

Les fourchettes ci-dessous sont des estimations maison issues de missions britanniques, exprimées en coût de première année incluant découverte, construction, tests et mise en service, mais hors temps des équipes de l’acheteur. Elles sont indicatives et non des devis, et les plages sont larges parce que les facteurs ci-dessus les déplacent.

Dit sans le tableau : un service unique avec deux ou trois intégrations, un usage interne et une cible de 99,5 pour cent se situe entre GBP 120 000 et GBP 250 000 la première année. Un système départemental face au client avec cinq à huit intégrations à 99,9 pour cent revient à GBP 300 000 jusqu’à GBP 700 000. Une plateforme centrale remplaçant un système existant, avec dix à vingt intégrations et une cible de 99,95 pour cent, revient à GBP 900 000 jusqu’à GBP 2,5 millions. Un programme régulé multi-entités à 99,99 pour cent démarre autour de GBP 2,5 millions et monte.

Le coût de fonctionnement qui n’est pas au budget

Ajoutez par-dessus un coût annuel de fonctionnement, qui se situe entre quinze et vingt-cinq pour cent du coût de construction par an une fois inclus le support, l’hébergement, les correctifs, le travail de sécurité et une enveloppe de changement modeste. Un budget qui finance la construction et pas le fonctionnement produit un système qui se dégrade visiblement dès sa deuxième année, et notre décomposition du coût de maintenance logicielle expose où va cet argent.

Sortie et continuité

Un fournisseur que vous ne pouvez pas quitter est un risque posé sur votre bilan, et c’est la clause le plus souvent renvoyée à la fin de la négociation, quand plus personne ne fait attention. Quatre choses rendent une sortie possible.

Le code source et son historique appartiennent à un dépôt que l’acheteur possède ou peut reprendre sur préavis, avec la chaîne de construction et les définitions d’infrastructure. Du code sans la chaîne qui le construit est une archive, pas un actif exploitable.

La documentation doit permettre à un tiers compétent d’exploiter le système : architecture, contrats d’intégration, procédures pour les modes de panne réellement survenus, et inventaire des accès. Notre article sur la documentation technique qui se lit décrit ce qui survit à une reprise.

Le séquestre couvre la défaillance du fournisseur plutôt que son départ, en déposant le source chez un tiers pour libération sur déclencheurs définis. Il vaut la peine là où le fournisseur est petit au regard du contrat, et il vaut la peine d’être lu attentivement, car un dépôt non vérifié libère du code qui ne se construit pas. Nous avons examiné quand il se justifie dans le séquestre logiciel, qui en a vraiment besoin.

Enfin, chiffrez la réversibilité dans le contrat. Un nombre nommé de jours de transfert de connaissance à un tarif convenu, déclenché sur préavis, transforme une dispute en facture. La même discipline vaut pour les fournisseurs de vos fournisseurs, traitée dans notre note sur la sécurité de la chaîne d’approvisionnement logicielle.

Juger la crédibilité d’entreprise d’un fournisseur en une réunion

Cinq questions établissent l’essentiel en une heure, et l’hésitation vous en dit autant que la réponse.

Demandez contre quels objectifs de disponibilité et de reprise ils ont livré, et comment la disponibilité était mesurée. Un fournisseur qui a porté une obligation de 99,95 pour cent nomme le point de mesure et l’organisation d’astreinte sans qu’on le lui demande. Celui qui ne l’a pas fait parle de redondance en général.

Demandez à voir la déclaration de périmètre de leur certificat ISO 27001, ou la section des exceptions de leur SOC 2 de type 2. Ce sont des demandes ordinaires pour un fournisseur qui les détient, et gênantes pour celui qui a un logo. Demandez ensuite comment ils ont traité un écart de rapprochement en production, ce que personne ne peut inventer en théorie.

Demandez de combien leurs trois derniers programmes ont dépassé, et pourquoi. Tout le monde dépasse, et la partie informative est de savoir s’ils connaissent le chiffre. Demandez enfin à quoi ressemble leur processus de sortie, en jours et en livrables. Un fournisseur qui l’a écrit s’attend à être jugé dessus.

Ce que cela laisse à un acheteur

Le mot entreprise devrait décrire des obligations, pas une gamme de prix. Une fois écrits la surface d’intégration, les objectifs de disponibilité et de reprise, l’exposition réglementaire et les conditions de sortie, la liste courte se trie d’elle-même, parce que la plupart des fournisseurs ne peuvent rien prouver contre ces quatre points.

Mecanik travaille sur cette forme d’engagement à travers nos services de développement logiciel, et sur le volet assurance à travers nos services de test d’intrusion. Si vous assemblez le besoin plutôt que la liste courte, la checklist de due diligence technique est un point de départ raisonnable, et les chiffres non fonctionnels méritent d’être discutés en premier.

Questions fréquentes

Qu’est-ce qui compte comme développement logiciel d’entreprise ? L’entreprise se définit par des contraintes plutôt que par la taille de l’acheteur. Un projet se qualifie quand il a une large surface d’intégration détenue par plusieurs parties, une obligation contractuelle de disponibilité et de reprise, une exposition réglementaire, plusieurs groupes de parties prenantes capables chacun de bloquer une livraison, des volumes de données qui cassent les conceptions naïves, et l’obligation de coexister avec des systèmes existants que personne ne comprend entièrement. Une grande société peut commander un projet ordinaire, et une petite entreprise régulée un projet réellement d’entreprise.

Combien coûte un programme logiciel d’entreprise au Royaume-Uni ? En estimations maison issues de missions britanniques, un service unique avec deux ou trois intégrations et une cible de disponibilité de 99,5 pour cent revient à GBP 120 000 jusqu’à GBP 250 000 la première année. Un système départemental face au client à 99,9 pour cent revient à GBP 300 000 jusqu’à GBP 700 000. Une plateforme centrale remplaçant un système existant revient à GBP 900 000 jusqu’à GBP 2,5 millions. Ajoutez de quinze à vingt-cinq pour cent du coût de construction par an pour le fonctionnement et le support.

Un fournisseur d’entreprise doit-il avoir ISO 27001, Cyber Essentials ou SOC 2 ? Ils prouvent des choses différentes. Cyber Essentials est un socle soutenu par le gouvernement britannique, fait de cinq contrôles techniques, avec un niveau Plus vérifié par audit technique indépendant et exigé par PPN 014 pour beaucoup de marchés publics. ISO/IEC 27001:2022 certifie un système de management de la sécurité de l’information, si bien que la déclaration de périmètre du certificat compte plus que le certificat. SOC 2 est un rapport d’attestation américain émis par un cabinet d’experts-comptables, et seul un type 2 teste si les contrôles ont fonctionné sur une période.

Que sont les objectifs de point de reprise et de temps de reprise ? L’objectif de point de reprise est la quantité de données que vous acceptez de perdre après un sinistre, donc un RPO d’une heure signifie que jusqu’à une heure de transactions peut disparaître. L’objectif de temps de reprise est la durée pendant laquelle vous acceptez d’être indisponible, donc un RTO de quatre heures signifie que le service doit servir de nouveau du trafic sous quatre heures. Les deux pèsent sur l’architecture et le coût plus que n’importe quelle fonctionnalité, car ils choisissent entre sauvegarde et restauration, veilleuse, secours tiède et multi-site actif/actif.

Que doit contenir un contrat logiciel d’entreprise sur la sortie ? Quatre choses. La propriété ou un accès transférable au dépôt de code source, à la chaîne de construction et aux définitions d’infrastructure. Une documentation suffisante pour qu’un tiers compétent exploite le système, y compris les procédures d’exploitation et l’inventaire des accès. Un séquestre du code source là où le fournisseur est petit au regard de la valeur du contrat, avec des dépôts vérifiés plutôt que non vérifiés. Et une clause de réversibilité chiffrée nommant les jours de transfert de connaissance et le tarif, pour que partir soit une facture et non un litige.