Référentiel IAS

Explorez les critères et barèmes que nous utilisons pour évaluer les solutions.

Pilier Critère Barème de Notation
AS1
Maîtrise des données & juridiction
 AS1-1 Nationalité et implantation du siège de l'éditeur

Évaluation de l'exposition de l'entité responsable (éditeur ou mainteneur) aux lois extra-européennes. L'analyse porte sur le siège social et l'assujettissement aux lois à portée extraterritoriale (ex: Cloud Act, FISA).
0 Siège social hors UE et/ou soumis à des lois extra-territoriales intrusives sans garanties de protection des données.
1 Siège hors UE mais bénéficiant d'une décision d'adéquation.
3 Siège social et centre de décision effectif en Union européenne.
5 Siège social et gouvernance situés en France.
AS1
Maîtrise des données & juridiction
 AS1-2 Localisation de l'hébergement

Pays où les serveurs sont situés
0 Hébergement hors UE.
1 Hébergement UE via hyperscaler non souverain.
3 Hébergement UE (non certifié SecNumCloud).
5 Hébergement certifié SecNumCloud ou auto-hébergement possible.
AS1
Maîtrise des données & juridiction
 AS1-3 Confidentialité technique et maîtrise du chiffrement

Évaluation de la protection des données contre les accès non autorisés, y compris par le fournisseur ou l'hébergeur. Mesure l'étanchéité technique de la solution face à l'espionnage industriel ou aux réquisitions extra-territoriales.
0 Pas de chiffrement au repos ou chiffrement partiel des flux. Les données circulent ou sont stockées de manière lisible par l'hébergeur.
1 Données chiffrées au repos et en transit, mais l'hébergeur détient et gère les clés. La confidentialité repose uniquement sur un engagement contractuel ou juridique.
3 L'organisation apporte ou gère ses propres clés de chiffrement. L'hébergeur y accède pour le traitement, mais n'en a pas la garde permanente.
5 Chiffrement de bout en bout. L'hébergeur n'a jamais accès aux clés ni aux données en clair. Seul⸱e l'utilisateur⸱rice final⸱e peut déchiffrer les informations.
AS1
Maîtrise des données & juridiction
 AS1-4 Conformité réglementaire et protection des données

Évaluation de l'aptitude du produit à respecter le cadre légal (ex: RGPD) et à protéger l'utilisateur⸱rice contre les risques juridiques. Mesure l'engagement de l'entité responsable dans la veille et l'application des normes de protection de la vie privée.
0 Le produit ne respecte pas les principes de base. L'entité responsable décline toute responsabilité quant à la conformité.
1 L'entité reconnaît les réglementations sans proposer d'outils d'aide. L'implémenteur doit configurer manuellement et à ses risques les mécanismes de protection.
3 Toutes les réglementations applicables au produit en matière de protection des données et de confidentialité ont été analysées pour le marché cible. Le produit comprend des mesures visant à faciliter et à garantir la conformité de l'utilisateur⸱rice, mais il ne surveille pas systématiquement les mises à jour ou les modifications apportées à la réglementation.
5 Le produit dispose d'un cadre de conformité robuste, comprenant une analyse complète de toutes les réglementations applicables en matière de protection des données et de confidentialité pour le marché cible. Il aide activement le responsable de la mise en œuvre à maintenir la conformité et suit systématiquement les mises à jour des exigences ou des réglementations afin de garantir une conformité continue.
AS2
Gouvernance
 AS2-1 Structure juridique et finalité de l'entité

Évalue la nature juridique de l'organisation responsable du produit et l'alignement de ses intérêts avec ceux de l'utilisateur⸱rice. L'objectif est de mesurer le risque de changement de stratégie lié à des impératifs financiers (recherche de profit maximal, rachat, sortie de bourse).
0 Acteur privé lucratif sous contrôle d'actionnaires externes (société cotée, fonds d'investissement). La priorité est la rentabilité financière, induisant un risque élevé de captivité ou de pivot commercial.
1 Acteur privé lucratif de type TPE/PME/ETI. Bien que plus agile, la structure reste vulnérable à un rachat ou à une faillite, avec une gouvernance centrée sur les propriétaires.
3 Acteur privé avec des mécanismes de protection (ex: agrément ESUS, coopérative/SCOP, ou État) ou communauté de bénévoles non constituée. L'intérêt métier prime, mais la structure peut manquer de garanties contractuelles fortes.
5 Organisation à but non lucratif (fondation, association) dont les statuts sanctuarisent le développement du produit comme un bien commun. Absence constitutionnelle de recherche de profit, garantissant une stabilité des objectifs à long terme.
AS2
Gouvernance
 AS2-2 Transparence de la feuille de route

Mesure de la capacité des utilisateurs à anticiper, auditer et orienter les évolutions fonctionnelles. L'analyse porte sur la publicité des développements et l'ouverture des processus décisionnels de l'entité responsable.
0 Absence de visibilité, aucune feuille de route publique.
1 Feuille de route publique, mais informative uniquement. Les décisions sont prises de manière unilatérale par l'éditeur sans mécanisme de retour utilisateur⸱rice.
3 Gouvernance consultative, feuille de route à jour avec un canal de recueil des besoins (ex: ticketing, forum). Les priorités sont affichées mais l'arbitrage final reste fermé.
5 Gouvernance ouverte et contributive, processus de hiérarchisation transparent. L'utilisateur⸱rice ou la communauté peut influencer directement les priorités via un système de vote ou de financement de fonctionnalités (co-construction).
AS2
Gouvernance
 AS2-3 Souveraineté de l'actionnariat et contrôle

Analyse de l'origine des capitaux et des droits de vote pour identifier les risques d'ingérence.
0 Contrôle majoritaire par des entités extra UE.
1 Influence significative ou minorité de blocage hors UE.
3 Actionnariat majoritairement européen mais sans protection contre un rachat.
5 Capital 100% souverain ou verrouillé (fondation, association, coopérative, état, ou capital distribué).
AS2
Gouvernance
 AS2-4 Participation à la prise de décision de la solution

Évaluation de la structure de commandement du produit. Mesure la capacité de l'utilisateur⸱rice ou d'un collège d'acteurs de confiance à exercer un contrôle sur les orientations stratégiques et à s'opposer à des décisions unilatérales (minorité de blocage).
0 Gouvernance opaque ou inexistante. Le développement est piloté exclusivement par une entité privée sans droit de regard externe.
1 Il n'existe aucune structure de gouvernance communautaire pour diriger le développement continu de l'outil numérique.
3 Il existe certains processus informels de gestion communautaire visant à orienter le développement continu de l'outil numérique.
5 Des structures communautaires existent et sont mises en œuvre de manière transparente, avec des rôles et des responsabilités documentés, et sont utilisées pour orienter le développement continu de l'outil numérique.
AS3
Licence et Ouverture
 AS3-1 Disponibilité du code

La mesure dans laquelle le produit est convivial pour les développeur⸱euses, de sorte qu'une personne technique qui ne connaît pas le produit puisse y contribuer. Cela inclut la mesure dans laquelle le code source est organisé et documenté, ainsi que la mesure dans laquelle d'autres documents destinés aux développeur⸱euses facilitent le processus d'intégration.
0 Code source non accessible au public.
1 Le code source existe dans un référentiel nécessitant une habilitation ou un accord spécifique.
3 Le code source existe dans un référentiel accessible au public.
5 Le code source est disponible dans un référentiel accessible au public. Le logiciel est structuré de manière à permettre des personnalisations locales et l'ajout de nouveaux modules et fonctionnalités sans nécessiter la création d'une branche du code principal.
AS3
Licence et Ouverture
 AS3-2 Nature de la licence et protection contre la fermeture

Analyse du régime juridique du code et des garanties de maintien de l'ouverture. L'objectif est d'évaluer la protection contre le #emph[relicensing] (changement de licence) et la capacité de la solution à rester un bien commun numérique sur le long terme.
0 Propriétaire et fermé. L'usage, la modification et la redistribution sont interdits. L'organisation est totalement dépendante du bon vouloir de l'éditeur pour la survie du produit.
1 Licence Open Source permissive (ex: MIT, Apache 2.0). Le code est libre, mais l'absence de copyleft permet à l'éditeur ou à un tiers de créer une version propriétaire dérivée. Risque de détournement de la valeur sans retour à la communauté (ex: Redis, Valkey).
3 Licence libre à réciprocité (Copyleft type GPL, AGPL) avec propriété intellectuelle détenue par un acteur privé. La licence protège contre la fermeture des contributions, mais l'éditeur peut décider de changer la licence des versions futures (relicensing) s'il possède tous les droits (ex: MySQL -> MariaDB).
5 Licence libre à réciprocité (Copyleft type GPL, AGPL) avec propriété intellectuelle détenue par une fondation ou un organisme public. Toute fermeture est juridiquement impossible. Le caractère bien commun est sanctuarisé par l'impossibilité pour un acteur unique de changer la licence (ex: Linux, WordPress, ...).
AS3
Licence et Ouverture
 AS3-3 Transparence et accessibilité du cycle de développement

Évalue la disponibilité réelle du code source et la capacité de l'utilisateur⸱rice à auditer le produit en continu. L'objectif est de distinguer la publication d'instantanés, du développement ouvert permettant une correction immédiate des vulnérabilités.
0 Code fermé. L'audit est impossible ou strictement réservé à des tiers choisis et rémunérés par l'éditeur. Aucun contrôle indépendant n'est permis.
1 Accessibilité restreinte ou différée. Le code est consultable sous accord de confidentialité ou publié périodiquement après la sortie des versions (ex: modèle RHEL ou Android AOSP). Le processus de développement reste privé.
3 Code source public et auditable à tout moment. Le code est accessible dans un dépôt public, mais le processus de décision et les correctifs en cours de préparation (staged) ne sont pas visibles avant leur publication officielle.
5 Développement ouvert. Le code est développé publiquement en temps réel (dépôt de code public). L'utilisateur⸱rice peut auditer les correctifs avant même leur publication et suivre les discussions techniques des développeur⸱reuses.
AS4
Interopérabilité & Réversibilité
 AS4-1 Standards de données

Utilisation de formats ouverts et documentés pour l'import/export de données (ex: JSON, XML, ODF).
0 Formats propriétaires fermés. Lecture impossible sans le logiciel.
1 Export limité à des formats pauvres (PDF, CSV mal structuré).
3 Formats ouverts structurés et documentés (JSON, SQL, XML).
5 Normes internationales natives (ODF, IFC, ISO) garantissant la pérennité
AS4
Interopérabilité & Réversibilité
 AS4-2 Qualité des API

Utilisation de normes ouvertes et conception modulaire afin de permettre la réversibilité. Les données peuvent être facilement exportées depuis le système.
0 Aucune API disponible (saisie manuelle ou scraping requis). Formats propriétaires fermés. Lecture impossible sans le logiciel.
1 L'extraction ou l'importation de données dans le système nécessite généralement de consulter le code source et/ou d'accéder directement à la base de données.
3 Certaines API sont disponibles pour accéder aux données et les gérer. Il existe des interfaces utilisateur⸱rice permettant d'exporter les données de base et les métadonnées du système (par exemple au format CSV).
5 Une API robuste est disponible pour répondre aux besoins clés en matière d'échange de données et de métadonnées.
AS4
Interopérabilité & Réversibilité
 AS4-3 Multi-plateforme

Capacité à s'exécuter sur différents environnements sans dépendance exclusive.
0 Verrouillage de la solution à un système d'exploitation spécifique (ex: Windows).
1 Dépendance à un moteur d'exécution ou un framework propriétaire.
3 Support de plusieurs systèmes d'exploitation via conteneurisation ou clients dédiés.
5 Agnostique : client universel garantissant une expérience identique partout.
AS4
Interopérabilité & Réversibilité
 AS4-4 Capacité d'ingestion et de reprise de l'existant

Évalue la capacité de la solution à importer et à intégrer les données provenant des outils externes. L'objectif est de mesurer la disponibilité d'outils de migration permettant de conserver l'historique, les structures et les métadonnées lors du changement de plateforme.
0 Aucun outil d'import n'est disponible. La reprise des données doit se faire manuellement ou via des saisies fastidieuses, induisant un risque de perte d'information.
1 La solution supporte l'import de fichiers bruts, mais nécessite des scripts de conversion pour traiter les formats spécifiques (ex: .pst, .ost). Les relations entre les données (calendriers, droits d'accès) sont perdues.
3 Il existe des connecteurs ou des procédures documentées pour les sources les plus courantes. Le transfert est fonctionnel mais peut demander des ajustements manuels post-migration.
5 La solution dispose d'outils de migration automatisés et certifiés pour les standards du marché. L'intégralité des données et métadonnées est réintrégrable dans la nouvelle solution.
AS4
Interopérabilité & Réversibilité
 AS4-5 Facilité d'extraction et réversibilité

Existence d'une procédure outillée et documentée pour exporter l'intégralité des données.
0 Données prisonnières. Aucun export global possible.
1 Export complexe nécessitant un développement technique.
3 Procédure d'export complète mais manuelle et chronophage.
5 Réversibilité automatisable nativement comprenant les données et métadonnées).
AS4
Interopérabilité & Réversibilité
 AS4-6 Architecture modulaire et composabilité

Mesure le degré de modularité et d'extensibilité de la solution. Une architecture découpée en briques interchangeables garantit l'agilité, la réutilisation et l'indépendance vis-à-vis d'un fournisseur unique.
0 Architecture monolithique. Les composants sont étroitement liés. Toute modification locale nécessite un 'fork' ou une altération directe du code source principal.
1 Modularité limitée. L'architecture permet l'ajout de quelques extensions ou plugins via des interfaces prédéfinies, mais le cœur reste rigide et indissociable.
3 Conception orientée services. La solution est composée de modules fonctionnels indépendants et interchangeables (Microservices ou API-first), facilitant l'adaptation aux besoins métiers.
5 Écosystème composable et standardisé. Architecture nativement modulaire utilisant des standards ouverts. Chaque composant peut être remplacé ou maintenu par des entités distinctes sans compromettre l'intégrité de l'ensemble.
AS5
Coût & Support
 AS5-1 Modèle de facturation

Prédictibilité des coûts et absence de frais cachés ou de sortie.
0 SaaS captif avec métriques imprévisibles et frais de sortie.
1 Abonnement avec historique de hausses unilatérales fréquentes.
3 Licence perpétuelle ou abonnement avec prix fixe contractuel.
5 TCO maîtrisé. Modèle stable sans frais de sortie ni captivité
AS5
Coût & Support
 AS5-2 Transparence et capacité de projection budgétaire

Évalue la capacité de l'organisation à modéliser le coût total de possession (TCO) de manière autonome. L'objectif est de mesurer la disponibilité de données chiffrées (besoins en serveurs, ressources humaines d'exploitation, infrastructure) permettant d'anticiper les dépenses sans subir les hausses unilatérales d'un fournisseur.
0 Opacité tarifaire et dépendance. Le modèle repose sur des licences SaaS ou propriétaires avec des métriques de facturation variables et imprévisibles. Historique de hausses unilatérales ou frais cachés (frais de sortie, API payantes) empêchant toute projection fiable.
1 Visibilité budgétaire limitée. Seuls les coûts directs (licences) sont connus. Les coûts indirects d'infrastructure et de maintenance sont peu documentés, rendant le calcul du TCO complexe et sujet à des erreurs d'estimation importantes.
3 Directives budgétaires basées sur l'usage. Existence de retours d'expérience (REX) de déploiements actifs fournissant des ratios de haut niveau (ex: nombre d'utilisateurs par serveur). Permet de planifier un budget de fonctionnement cohérent mais encore approximatif.
5 Modélisation capacitaire exhaustive. Disponibilité de données détaillées et publiques couvrant l'intégralité des coûts : dimensionnement matériel (CPU/RAM/Stockage), temps humain nécessaire à l'exploitation (ETP), et coûts de formation. L'organisation peut bâtir un business plan précis et indépendant pour un déploiement à grande échelle.
AS5
Coût & Support
 AS5-3 Indépendance et ouverture de l'écosystème de maintenance

Évalue la diversité des acteurs capables d'assurer le support technique et la maintenance corrective. L'objectif est de mesurer le risque de dépendance économique vis-à-vis d'un prestataire unique et la liberté de l'organisation à changer de partenaire de support.
0 Monopole éditeur. Seul l'éditeur détient les droits et les capacités techniques pour corriger les bugs ou assurer le support. L'organisation subit unilatéralement les tarifs et les délais imposés.
1 Marché fermé ou captif. Le support est délégué à un réseau restreint de partenaires strictement contrôlés par l'éditeur. La concurrence est limitée et les méthodes d'intervention restent opaques ou propriétaires.
3 Marché concurrentiel régulé. Plusieurs prestataires indépendants et certifiés sont présents sur le marché. L'organisation peut changer de partenaire de support, bien que l'accès aux correctifs de bas niveau (bugs critiques) dépende encore d'une validation finale de l'éditeur.
5 Écosystème ouvert et souverain. Le code étant libre et la documentation publique, n'importe quelle ESN ou l'équipe interne peut assurer la maintenance complète (y compris corrective). La concurrence est large, garantissant une maîtrise des coûts et une pérennité indépendante de l'éditeur d'origine.
AS5
Coût & Support
 AS5-4 Qualité de la documentation et autonomie d'exploitation

Évalue la richesse des ressources techniques permettant l'installation, la configuration et le maintien en condition opérationnelle (MCO) de la solution. L'objectif est de mesurer la capacité des équipes internes à devenir autonomes sans dépendre systématiquement du support éditeur.
0 Documentation inexistante ou cryptique. Le fonctionnement interne de la solution est une 'boîte noire'. Toute intervention technique nécessite l'appel à l'éditeur, créant une dépendance opérationnelle totale.
1 Documentation sommaire, fragmentée ou obsolète. Les procédures critiques (mise à jour, sauvegarde, debug) sont peu documentées ou nécessitent une ingénierie inverse.
3 Documentation technique complète et structurée par l'éditeur (Guides AdminSys, API, schémas d'architecture). Elle permet une exploitation efficace.
5 Patrimoine de connaissances exhaustif, public et contributif (Wiki, documentation officielle détaillée, FAQ communautaire). Présence de ressources d'automatisation et de forums d'entraide actifs permettant de résoudre les incidents complexes en totale autonomie.
AS5
Coût & Support
 AS5-5 Disponibilité des compétences sur le marché

Mesure la facilité pour l'organisation de recruter des profils qualifiés ou de trouver des prestataires externes maîtrisant la solution. Un score élevé garantit que l'organisation ne sera pas bloquée par une pénurie de main-d'œuvre spécialisée.
0 Expertise confidentielle ou de niche. Très peu de professionnels maîtrisent l'outil. Le départ d'un seul collaborateur ou la défaillance d'un prestataire unique met en péril le maintien en condition opérationnelle.
1 Compétences rares et coûteuses. Quelques experts identifiés, mais le marché est en tension. Le recrutement est long et nécessite souvent des formations spécifiques lourdes après l'embauche.
3 Expertise établie et accessible. La solution est enseignée dans certains cursus ou maîtrisée par de nombreuses ESN. Il est possible de recruter ou de sous-traiter dans des délais raisonnables.
5 Standard du marché. La compétence est largement répandue (ex: administrateur Debian, développeur Python). Abondance de profils certifiés et de prestataires en concurrence, garantissant une flexibilité maximale et des coûts de prestation maîtrisés.
AS5
Coût & Support
 AS5-6 Ergonomie du produit

Évalue la qualité de l'interface et la proximité avec les standards de l'industrie. Un score élevé permet de réduire les besoins en formation et les risques de rejet de la solution par les collaborateur⸱rices.
0 Interface austère ou obsolète. Ergonomie non conforme aux standards actuels du Web ou du bureau. Nécessite une formation systématique pour chaque nouvel utilisateur⸱rice sous peine d'incapacité de travail.
1 Interface complexe ou contre-intuitive. Les flux de travail sont sensiblement différents des habitudes acquises. Risque élevé de baisse de productivité initiale et de forte résistance au changement.
3 Interface moderne et fonctionnelle. L'ergonomie est soignée et respecte les conventions usuelles. Un⸱e utilisateur⸱rice standard retrouve ses marques avec un temps d'adaptation minimal (auto-formation possible).
5 Expérience utilisateur⸱rice de premier plan. L'interface est jugée supérieure ou équivalente aux solutions propriétaires hégémonique du marché. Intègre des fonctions d'accessibilité (RGAA) et d'aide à la prise en main qui facilitent une adoption immédiate sans formation préalable.
AS6
Pérennité & Sobriété
 AS6-1 Vitalité et résilience de l'écosystème

Mesure la pérennité technique à travers l'activité de développement et la diversité des contributeur⸱rices. Un score élevé garantit que le logiciel évolue face aux menaces de sécurité et ne dépend pas d'un groupe restreint d'individus (facteur de bus).
0 Projet moribond. Aucune mise à jour de sécurité depuis plus de 6 mois. La dette technique accumulée rend la solution vulnérable et obsolète à court terme.
1 Dépendance critique (Facteur de bus = 1). Le développement repose sur un individu seul ou une micro-équipe sans relais. Tout arrêt de leur part entraîne l'arrêt immédiat du support technique.
3 Communauté active et structurée. Présence de contributeur⸱rices régulier⸱es et cycles de publication documentés. La maintenance est assurée, mais le projet reste majoritairement porté par une seule entité ou un petit noyau de développeur⸱euses.
5 Pluralité d'acteurs indépendants (entreprises, fondations, bénévoles) contribuant au code. La gouvernance du développement est décentralisée, garantissant la survie du projet même en cas de retrait d'un⸱e contributeur⸱rice majeur⸱e.
AS6
Pérennité & Sobriété
 AS6-2 Diversité du financement

Stabilité économique et dépendance financière du projet.
0 Dépendance critique à un seul donateur ou un seul gros client.
1 Financement par dette ou capital-risque à court terme (risque pivot stratégique).
3 Modèle économique diversifié (services, licences, fondations).
5 Financement pérenne, distribué et indépendant d'un seul acteur.
AS6
Pérennité & Sobriété
 AS6-3 Éco-conception et efficacité matérielle

Mesure l'optimisation du logiciel et son empreinte sur les ressources (CPU, RAM, stockage). Une solution sobre permet de retarder le renouvellement du matériel (limitation des déchets électroniques) et réduit la consommation énergétique globale.
0 Logiciel obèse. Consommation de ressources disproportionnée par rapport aux fonctionnalités. Exige systématiquement du matériel de dernière génération pour fonctionner de manière fluide.
1 Optimisation limitée. Pas de prise en compte des principes d'éco-conception. La consommation énergétique est élevée et le logiciel présente des fuites de ressources (ex: fuites mémoire) non corrigées.
3 Code optimisé et stable. La solution fonctionne correctement sur du matériel standard ou reconditionné. L'éditeur communique sur l'optimisation des performances et la réduction de l'empreinte carbone du produit.
5 Sobriété native. Logiciel conçu pour une efficacité maximale. Capacité à s'exécuter sur des configurations anciennes sans dégradation de l'expérience utilisateur⸱rice.
AS6
Pérennité & Sobriété
 AS6-4 Conformité et accessibilité numérique

Évalue l'accessibilité de l'interface pour les personnes en situation de handicap (visuel, auditif, moteur). Un score élevé garantit l'inclusivité de l'outil et la conformité aux obligations légales (RGAA en France, EN 301 549 en Europe).
0 Inaccessible. L'interface ne supporte aucun outil d'assistance (lecteurs d'écran, navigation clavier seule). Absence totale de contraste ou d'alternatives textuelles.
1 Accessibilité partielle et non documentée. Quelques efforts sur les contrastes, mais les flux de travail critiques (formulaires, menus complexes) restent bloquants pour de nombreux⸱se utilisateur⸱rices.
3 Bon niveau d'accessibilité. La solution respecte les principes de base des WCAG ou du RGAA. L'interface est largement compatible avec les technologies d'assistance, bien que quelques fonctions avancées nécessitent des ajustements.
5 Exemplarité et conformité totale. La solution dispose d'une déclaration de conformité (VPAT ou audit RGAA) avec un taux proche de 100%. L'accessibilité est intégrée dès la conception et l'interface est nativement inclusive.
AS6
Pérennité & Sobriété
 AS6-5 Rétro-compatibilité

Mesure la capacité du produit à maintenir son fonctionnement sur des infrastructures existantes et à garantir la stabilité des interfaces lors des mises à jour. Une forte rétro-compatibilité protège contre l'obsolescence subie et réduit les coûts de migration forcée.
0 Obsolescence rapide. Pas de support des versions antérieures. Les mises à jour imposent systématiquement une montée de version matérielle ou une rupture des interfaces (API/données).
1 Support court terme. Rétro-compatibilité limitée à la version immédiatement précédente. Cycle de vie des versions inférieur à 2 ans, forçant des migrations fréquentes et coûteuses.
3 Stabilité garantie. Existence de versions à support étendu garanties sur plusieurs années. Compatibilité ascendante maintenue pour les fonctions critiques.
5 Continuité et sobriété. Engagement de compatibilité sur le matériel ancien (Low-tech) et maintien strict de la compatibilité des API/données sur le très long terme.