4  Contraintes non-fonctionnelles

Les contraintes non-fonctionnelles sont souvent négligées alors qu’elles conditionnent directement la viabilité, la maintenabilité et la conformité d’un système dans la durée. Cela peut comprendre des contraintes de mise en conformité, d’accessibilité, de sécurité, de localisation ou de traçabilité.

4.1 Case study : GDPR : une contrainte non-fonctionnelle… mais très architecturale

Le RGPD (ou GDPR en anglais) n’est pas juste une affaire de juristes. Dès qu’un système collecte, stocke ou traite des données personnelles (nom, e-mail, adresse IP, etc.), il tombe sous le coup de ce règlement. Et ce cadre légal introduit des contraintes qui influencent directement les choix d’architecture.

4.1.1 Ce que le GDPR impose techniquement

Voici quelques exemples concrets d’exigences réglementaires… et leurs implications techniques :

• Droit à l’effacement → suppression ciblée de données dans plusieurs systèmes ou bases distribuées.
• Portabilité des données → export complet, structuré et interopérable des données personnelles.
• Consentement explicite → gestion centralisée du consentement, horodatée, traçable, versionnée.
• Minimisation des données → ne stocker que ce qui est strictement nécessaire, et pour une durée définie.
• Sécurité → chiffrement des données au repos et en transit, journalisation, cloisonnement des accès.

Dit autrement : on ne peut pas “régler le GDPR” en fin de projet. Ces exigences structurent la manière dont on conçoit les modules, la base de données, les API, les logs ou encore les backups.

4.1.2 Quelles implications pour l’architecture ?

Le GDPR pousse à adopter certains réflexes architecturaux :

• Séparer les données personnelles du reste des données métier.
• Identifier et tracer chaque point de collecte ou d’accès aux données.
• Rendre les traitements explicites, réversibles et audités.
• Centraliser la gestion des préférences utilisateurs (consentement, opt-out).
• Prévoir des interfaces internes pour rechercher, modifier ou supprimer des données.

C’est ce qu’on appelle le Privacy by Design : intégrer la protection des données dès la conception.

4.1.3 Les 6 bons réflexes (selon la CNIL)

La CNIL propose une synthèse claire des bonnes pratiques, utile dès les premières étapes du design :

• Ne collectez que les données vraiment nécessaires.
• Soyez transparents sur leur usage.
• Respectez les droits des utilisateurs (accès, rectification, suppression).
• Gardez le contrôle sur les données et les sous-traitants.
• Identifiez les risques en amont.
• Sécurisez vos systèmes et vos traitements.

Ces points peuvent — et doivent — devenir des exigences non-fonctionnelles dans vos specs.

4.1.4 Exemple : la politique de confidentialité de Discord

Discord, comme beaucoup de plateformes grand public, expose une politique de confidentialité très détaillée. Elle décrit :

• Quelles données sont collectées (par l’utilisateur, automatiquement, via des tiers),
• Comment ces données sont utilisées et partagées,
• Combien de temps elles sont conservées,
• Quels droits les utilisateurs peuvent exercer,
• Quels transferts internationaux ont lieu.

Une telle politique a des implications directes sur l’architecture : modularité, gestion de l’identité, interopérabilité, journalisation, etc.

4.1.5 À retenir

Le GDPR n’est pas une couche légale qu’on ajoute après coup : c’est une contrainte transverse à prendre en compte dès le départ. Elle influence vos décisions comme peuvent le faire la performance, la sécurité ou la scalabilité.

Si votre système touche à des données personnelles, vous avez tout intérêt à architecturer pour la conformité.

4.2 Accessibilité : coder pour tout le monde

L’accessibilité (a11y) ne concerne pas qu’une poignée d’utilisateurs : elle améliore l’expérience globale, y compris pour ceux qui utilisent un clavier, un lecteur d’écran, ou qui ont une connexion lente.

4.2.1 Ce que l’accessibilité implique

• Navigation clavier → pouvoir se déplacer sans souris.
• Contrastes adaptés → bonne lisibilité même avec une vue réduite.
• Compatibilité lecteurs d’écran → bonne structure HTML, balises ARIA.
• Gestion des erreurs → messages explicites, non ambigus.
• Alternatives aux contenus visuels → texte alternatif, sous-titres, descriptions.

4.2.2 Impacts sur l’architecture (et surtout le frontend)

• Utiliser des composants accessibles dès le départ (ex. design system compatible WCAG).
• Respecter la sémantique HTML (titres hiérarchisés, rôles explicites).
• Prévoir des tests d’accessibilité automatisés (axe, pa11y, Lighthouse).
• Intégrer l’accessibilité dans les revues de code et les specs UI.

🎯 L’accessibilité n’est pas une option : c’est une exigence de qualité pour tous les utilisateurs.

4.3 Localisation et internationalisation : penser au-delà de la langue

Votre application n’a pas besoin d’être multilingue pour être concernée par la localisation. Dès qu’il y a des dates, des devises ou des formats, vous êtes confrontés à cette contrainte.

4.3.1 Exemples de cas concrets

• Traductions dynamiques → interface multilingue, messages utilisateur, erreurs.
• Formats locaux → date (dd/mm/yyyy ou mm/dd/yyyy), heure (12h vs 24h), monnaie (€ vs $).
• Fuseaux horaires → affichage d’horaires personnalisés, gestion du temps universel (UTC).

4.3.2 Impacts sur l’architecture

• Externaliser toutes les chaînes de caractères à traduire.
• Stocker les dates en UTC, les convertir à l’affichage.
• Prendre en compte la locale de l’utilisateur dans le backend ET le frontend.
• Éviter de coder des règles culturelles en dur (ex. lundi comme premier jour de la semaine).

🎯 Penser à l’internationalisation dès le départ, c’est éviter de devoir tout réécrire quand le produit s’ouvre à d’autres marchés.

4.4 Observabilité et traçabilité : comprendre ce que fait votre système

Un système qu’on ne peut pas observer est un système qu’on ne peut pas maintenir. L’observabilité, ce n’est pas juste “avoir des logs” — c’est concevoir une architecture qui permet de comprendre ce qui se passe en production.

4.4.1 Ce que l’observabilité couvre

• Logs structurés → information lisible et corrélée avec les événements métier.
• Métriques → temps de réponse, taux d’erreur, files d’attente, usage CPU/mémoire.
• Traces distribuées → suivre une requête à travers plusieurs services ou composants.
• Auditabilité → journalisation des actions sensibles (accès, suppression, changement de configuration).

4.4.2 Impacts sur l’architecture

• Chaque service doit pouvoir exposer ses métriques (Prometheus, OpenTelemetry).
• Chaque requête doit embarquer un trace ID unique.
• Les logs doivent être structurés (JSON, lignes clés) et stockés de manière centralisée (ELK, Datadog, Loki).
• Les erreurs doivent être capturées, catégorisées, analysables.

🎯 Concevoir un système observable, c’est comme prévoir des fenêtres dans un bâtiment : indispensable pour voir ce qui s’y passe — et intervenir en cas d’incendie.

4.5 Sécurité : une contrainte omniprésente

La sécurité est une exigence non-fonctionnelle centrale. Elle ne se limite pas à mettre un pare-feu ou un mot de passe fort : elle doit être intégrée à tous les niveaux de l’architecture.

4.5.1 Implication

• Contrôle d’accès → authentification, autorisation, gestion des rôles.
• Protection des données sensibles → chiffrement en transit (TLS) et au repos (AES, KMS), éventuellement au niveau applicatif.
• Gestion des identités → fédération d’identité (OAuth2, OpenID Connect), annuaires, SSO.
• Limitation de la surface d’attaque → séparation des responsabilités, minimalisme des privilèges.
• Auditabilité → traçabilité des actions critiques (accès, modification, suppression).

4.5.2 Impacts

• Centraliser l’authentification et la gestion des sessions.
• Appliquer le principe du least privilege sur les bases, APIs et accès infra.
• Définir des zones de confiance (tiers, périmètres réseau).
• Isoler les secrets (via un secrets manager).
• Intégrer des outils de surveillance des accès et d’alerte en cas d’anomalie.

🎯 La sécurité n’est pas un module : c’est une propriété transversale de tout le système.