Éthique, durabilité et analyse de rentabilité

Pourquoi les architectes ont besoin d’analyses de rentabilité

Le travail d’architecture est en concurrence, pour l’argent et les personnes, avec tout ce qu’une organisation veut faire d’autre. Une migration, une plateforme, un programme de résilience ou un remboursement de dette produit rarement une fonctionnalité visible par le client ; il est donc facile de le reporter au profit d’un travail qui en produit. Les architectes qui obtiennent le financement de ce travail ne sont généralement pas ceux qui ont les conceptions les plus élégantes, mais ceux qui savent exprimer leur argumentaire dans les termes que les décideurs utilisent pour comparer les investissements : ce que cela coûte, ce que cela rapporte, en combien de temps, avec quelle certitude, et ce qui se passe si on ne le fait pas. Cet argumentaire structuré est une analyse de rentabilité (business case).

C’est le versant métier de tout ce que ce cours a dit sur les compromis. Une analyse de rentabilité est un enregistrement de décision pour un investissement : contexte, options, critères, conséquences et recommandation, les conséquences étant exprimées autant que possible en argent, en temps et en risque. Elle ne remplace pas le jugement architectural, et une grande partie de ce que l’architecture protège (sécurité, apprentissage, optionalité) est difficile à chiffrer. Mais mettre des chiffres honnêtes là où c’est possible, et dire clairement là où ça ne l’est pas, donne le droit d’être entendu sur le reste.

Les organisations utilisent différents formats. Le Green Book du gouvernement britannique, publié par le HM Treasury, structure les dossiers du secteur public autour de cinq questions : le volet stratégique (pourquoi un changement est nécessaire), le volet économique (quelle option offre le meilleur rapport qualité-prix), le volet commercial (peut-on se le procurer), le volet financier (est-ce abordable) et le volet managérial (peut-on le mener à bien). La plupart des entreprises utilisent quelque chose de plus léger, mais ces mêmes questions méritent une réponse pour tout investissement d’architecture important.

Options, coûts, bénéfices et risques

Toute analyse de rentabilité devrait comparer au moins trois options : ne rien faire (la référence), faire le minimum et l’option recommandée, plus toute autre solution sérieuse. Ne rien faire est rarement gratuit. Le contrat de support du système hérité augmente, le taux d’incidents croît avec le trafic, et les changements deviennent de plus en plus lents ; cette dérive est la référence par rapport à laquelle on mesure les bénéfices des autres options, et l’omettre fait paraître chaque investissement moins intéressant qu’il ne l’est.

Les coûts et les bénéfices devraient être listés par catégorie, pour qu’aucun ne soit oublié ni compté deux fois. Les risques ont explicitement leur place dans l’analyse : à la fois les risques que l’investissement réduit, que l’on peut valoriser comme des pertes attendues évitées (probabilité multipliée par impact), et les risques de l’investissement lui-même, comme un dépassement ou des perturbations pendant la migration. Le coût du retard (cost of delay) de Don Reinertsen, tiré de The Principles of Product Development Flow (2009), offre un éclairage supplémentaire utile : la valeur perdue chaque semaine où un travail n’est pas livré. Diviser le coût du retard par la durée (weighted shortest job first) donne une manière défendable d’ordonner des travaux concurrents.

Enfin, structurez l’investissement en une série d’étapes avec des points de décision plutôt qu’en un seul gros engagement. La migration incrémentale de la section 11.6 en est un bon exemple : chaque étape livre quelque chose et produit des éléments probants ; le financement peut donc être débloqué étape par étape, et le programme arrêté si les bénéfices n’apparaissent pas. Des jalons de ce type transforment un pari risqué en un ensemble d’options plus petites ; c’est la réflexion sur la réversibilité de la section 1.6 appliquée à l’argent.

Valeur actuelle nette et délai de récupération

L’argent d’aujourd’hui vaut plus que l’argent de demain : il peut être investi, et l’argent futur est moins certain. Pour comparer des flux de trésorerie qui arrivent à des années différentes, les équipes financières convertissent chacun en sa valeur d’aujourd’hui, à l’aide d’un taux d’actualisation qui reflète le coût du capital de l’organisation et le risque de l’investissement. Le taux est normalement fixé par la direction financière, et les architectes devraient l’utiliser plutôt que d’en choisir un eux-mêmes.

La valeur actuelle nette d’un investissement est la somme de tous ses flux de trésorerie, chacun actualisé à aujourd’hui : VAN = Σ C_t ÷ (1 + r)^t, sommée sur les années t = 0 à n, où C_t est le flux de trésorerie net de l’année t (négatif pour les coûts) et r le taux d’actualisation annuel. Le flux de l’année 0 est l’investissement initial et n’est pas actualisé. Une VAN positive signifie que l’investissement rapporte plus que le taux d’actualisation ; pour choisir entre des options de risque comparable, celle qui a la VAN la plus élevée crée le plus de valeur.

Le délai de récupération est plus simple : combien de temps faut-il pour que le flux de trésorerie cumulé devienne positif ? Les dirigeants l’apprécient parce qu’il est facile à comprendre et qu’il rend compte du risque de manière sommaire (plus l’argent revient tôt, moins il y a de choses qui peuvent mal tourner), mais il ignore tout ce qui se passe après le point de récupération. Le délai de récupération actualisé fait le même calcul avec des flux de trésorerie actualisés. Présentez à la fois la VAN et le délai de récupération, et montrez leur sensibilité aux estimations qui comptent le plus.

def npv(rate, cash_flows):
    """cash_flows[0] is year 0 (the investment, usually negative)."""
    return sum(c / (1 + rate) ** t for t, c in enumerate(cash_flows))

flows = [-420_000, 150_000, 190_000, 190_000, 190_000]
print(round(npv(0.10, flows)))        # 145911
print(round(npv(0.15, flows)))        # 87663

pessimistic = [flows[0]] + [c * 0.7 for c in flows[1:]]
print(round(npv(0.10, pessimistic)))  # -23862

La dette technique en argent et en temps

La section 1.7 a présenté la dette technique comme un principal (le coût de correction d’un problème) et des intérêts (le surcoût payé à chaque changement tant qu’il subsiste), et a estimé les intérêts d’un module enchevêtré. Une analyse de rentabilité a besoin des mêmes grandeurs sous une forme que la finance reconnaît. Les intérêts deviennent un coût annuel ; le principal devient l’investissement ; et rembourser la dette devient un investissement dont le rendement est constitué des intérêts qu’on ne paie plus, plus toute réduction des risques et toute opportunité rendue possible.

Plusieurs types d’éléments probants peuvent être convertis. Temps de développement : les jours supplémentaires par changement, tirés de comparaisons avec des changements similaires ailleurs ou des estimations des développeurs, multipliés par le volume de changements et un coût journalier complet. Retard : l’allongement des délais multiplié par le coût du retard du travail concerné. Incidents : le nombre et la durée des incidents imputables à la dette, multipliés par leur coût. Risque : la probabilité et l’impact des défaillances que la dette rend plus probables, comme une faille de sécurité via un composant qui n’est plus pris en charge. Opportunité : les initiatives métier que la dette bloque purement et simplement.

Méfiez-vous des chiffres de dette produits par les outils d’analyse statique, qui indiquent généralement un effort de remédiation estimé (le temps qu’il faudrait pour corriger chaque problème signalé). C’est une estimation du principal, pas des intérêts, et cela ne dit rien de la fréquence à laquelle le code est modifié, ni même s’il l’est. La dette dans du code rarement touché coûte peu ; les hotspots de la section 1.7 sont là où les intérêts sont réellement payés, et là où le remboursement rapporte le plus. Présenter la dette comme un portefeuille de petits investissements, chacun avec un rendement et un délai de récupération estimés, est généralement bien plus convaincant qu’un chiffre global unique de la dette totale.

Éthique : ce que demandent les codes professionnels

Les décisions architecturales façonnent ce que les systèmes font aux personnes qui les utilisent et à celles qu’ils touchent sans leur consentement ; les architectes portent donc des responsabilités éthiques aussi bien que techniques. Deux codes professionnels sont particulièrement pertinents. Le Code d’éthique et de conduite professionnelle de l’ACM (ACM Code of Ethics and Professional Conduct), mis à jour par l’Association for Computing Machinery en 2018, s’ouvre sur des principes généraux : contribuer à la société et au bien-être humain, en reconnaissant que toutes les personnes sont parties prenantes de l’informatique ; éviter de nuire ; être honnête et digne de confiance ; être équitable et agir pour ne pas discriminer ; respecter le travail nécessaire pour produire des idées nouvelles ; respecter la vie privée ; et honorer la confidentialité. Ses responsabilités professionnelles comprennent le fait de fournir des évaluations complètes et approfondies des systèmes informatiques et de leurs impacts, y compris l’analyse des risques possibles, et de concevoir des systèmes dont la sécurité est robuste et utilisable ; ses principes de leadership demandent une attention particulière pour les systèmes qui s’intègrent à l’infrastructure de la société.

Le BCS Code of Conduct, de BCS, The Chartered Institute for IT au Royaume-Uni, s’organise autour de quatre devoirs : envers l’intérêt public (y compris la santé publique, la vie privée, la sécurité, le bien-être, l’environnement et l’égalité d’accès), envers la compétence et l’intégrité professionnelles, envers l’autorité compétente (l’employeur ou le client) et envers la profession. Le Software Engineering Code of Ethics commun à l’ACM et à l’IEEE Computer Society (1999) ajoute huit principes, à commencer par l’intérêt public, qui prime sur les intérêts du client et de l’employeur.

Pour les architectes, ces codes se traduisent par des obligations concrètes. Analysez les effets prévisibles d’une conception, et pas seulement sa justesse fonctionnelle. Informez honnêtement les décideurs des risques, y compris ceux qu’ils préféreraient ne pas entendre. Refusez de concevoir des systèmes destinés à tromper ou à nuire, et faites remonter le problème si on vous le demande. Consignez dans l’enregistrement de décision les désaccords fondés sur des motifs éthiques. Et sachez vers qui vous tourner si la remontée interne échoue : au Royaume-Uni, par exemple, le Public Interest Disclosure Act 1998 protège les travailleurs qui signalent certains types d’actes répréhensibles.

Dark patterns et autres préjudices prévisibles

Le tableau recense les préjudices le plus souvent à la portée d’un architecte. Plusieurs sont traités en profondeur ailleurs : la vie privée et la sécurité au chapitre 8, l’accessibilité en tant que qualité à la section 2.7, et les biais des systèmes d’apprentissage automatique au chapitre 12. L’accessibilité est de plus en plus une contrainte juridique autant qu’éthique ; dans l’UE, l’acte européen sur l’accessibilité s’applique depuis le 28 juin 2025 à de nombreux services aux consommateurs, dont le commerce électronique.

La conception manipulatrice mérite une mention particulière, car elle est souvent demandée délibérément. Harry Brignull a créé le terme dark pattern (interface truquée) en 2010 pour désigner des interfaces conçues pour amener les gens par la ruse à des choix qu’ils n’auraient pas faits autrement ; il préfère aujourd’hui parler de deceptive patterns (patrons trompeurs). Parmi les exemples familiers : la tarification au goutte-à-goutte (drip pricing, des frais révélés seulement à la fin), le confirmshaming (rendre l’option du refus honteuse), la fausse urgence et la fausse rareté, les cases de consentement précochées et les abonnements faciles à souscrire et difficiles à résilier. Les autorités ont réagi : le règlement européen sur les services numériques (Digital Services Act, 2022) interdit aux fournisseurs de plateformes en ligne de concevoir leurs interfaces en ligne de façon à tromper ou à manipuler les destinataires de leur service, et la Federal Trade Commission américaine a publié en 2022 un rapport de ses services sur les dark patterns. Beaucoup de ces patrons nécessitent un soutien architectural (une API de tarification qui masque les frais jusqu’à l’étape de paiement, un parcours de résiliation acheminé par un service de rétention) ; les architectes sont donc bien placés pour les repérer et les contester.

La manière la plus simple de rendre les préjudices visibles est de les chercher délibérément, aux mêmes moments que les risques techniques. Ajoutez une question sur les préjudices à la modélisation des menaces et aux revues de conception : qui pourrait être lésé par ce système quand il fonctionne comme prévu, quand il tombe en panne, ou quand il est détourné ? Des pratiques comme le consequence scanning, développé par le think tank britannique Doteveryone, donnent aux équipes un format court et structuré pour cette conversation pendant la planification.

Durabilité : le logiciel vert

Le logiciel ne brûle pas de carburant, mais l’électricité et le matériel qu’il utilise, si, et les décisions architecturales figent une grande partie de cette empreinte pour des années. La Green Software Foundation, lancée en 2021 sous l’égide de la Linux Foundation, publie six domaines fondamentaux de la pratique du logiciel vert : l’efficacité carbone (émettre le moins de carbone possible), l’efficacité énergétique (consommer le moins d’énergie possible), la conscience carbone (faire plus quand l’électricité est plus propre et moins quand elle est plus sale), l’efficacité matérielle (utiliser le moins de carbone incorporé possible), la mesure, et les engagements climatiques (comprendre exactement comment une réduction est obtenue).

L’informatique consciente du carbone (carbon-aware computing) exploite le fait que l’intensité carbone de l’électricité varie selon l’heure et la région, en fonction de la part de l’éolien, du solaire, du gaz et des autres sources. Le déplacement de la demande (demand shifting) déplace le travail flexible, comme les traitements par lots, l’entraînement de modèles, les sauvegardes et la génération de rapports, vers des moments ou des régions où l’électricité est plus propre ; le modelage de la demande (demand shaping) réduit ce que fait le logiciel quand elle est plus sale, par exemple en servant des médias de plus basse résolution ou en différant les recalculs non urgents. Les services de données sur le réseau électrique, comme la Carbon Intensity API pour la Grande-Bretagne, et des outils open source comme le Carbon Aware SDK de la fondation fournissent les signaux. À titre d’illustration simple, un traitement par lots nocturne qui consomme 400 kWh émet environ 120 kg CO₂e à un niveau illustratif de 300 g par kWh en début de soirée, mais environ 48 kg s’il est déplacé à une nuit venteuse à 120 g par kWh.

Le carbone incorporé (embodied carbon), c’est-à-dire les émissions liées à la fabrication et à l’élimination du matériel, est la raison pour laquelle l’efficacité matérielle compte : une utilisation plus élevée d’un nombre réduit de machines, la réduction à zéro en période d’inactivité et l’allongement de la durée de vie des appareils (y compris les téléphones des clients, en n’exigeant pas de nouveau matériel à chaque version) le réduisent tous. La spécification Software Carbon Intensity de la fondation, publiée sous la référence ISO/IEC 21031:2024 et présentée à la section 2.7, combine les émissions opérationnelles et incorporées par unité fonctionnelle, par exemple par commande livrée, et exclut la compensation carbone pour que seules les réductions réelles améliorent le score.

Parmi les leviers architecturaux : le dimensionnement au plus juste et l’autoscaling, la suppression des environnements inactifs, la limitation de la conservation des données (les données stockées ont un coût en énergie et en matériel), des formats de données efficaces et la mise en cache, le choix de régions dont le réseau électrique est plus propre lorsque la latence et la résidence des données le permettent, et la remise en question de la nécessité d’un appel à un grand modèle pour chaque fonctionnalité. Méfiez-vous de l’effet rebond, la forme moderne de l’observation faite en 1865 par William Stanley Jevons à propos du charbon : une efficacité qui rend quelque chose moins cher peut en augmenter l’usage total ; mesurez donc les émissions totales autant que l’intensité.