Contraintes et contexte¶

Les faits qui eliminent des options avant même d'ouvrir un outil de modélisation.

Pourquoi les contraintes sont des allies¶

Les contraintes sont des faits, pas des préférences. Elles eliminent des options avant même d'ouvrir un outil de modélisation. Les ignorer conduit à concevoir des architectures parfaites sur papier mais intenables en pratique.

Un architecte débutant voit les contraintes comme des obstacles. Un architecte experimente les voit comme un cadre qui accéléré les décisions. Quand le budget est de 500 EUR/mois et l'équipe de trois personnes, la moitie des options architecturales sont eliminees d'office. C'est une bonne nouvelle — moins d'options a évaluer, moins de debats, des décisions plus rapides.

Sans contraintes documentees, chaque réunion d'architecture risque de répartir de zero. Quelqu'un propose Kubernetes, quelqu'un d'autre rappelle que personne ne sait l'opérer, un troisieme dit "on pourrait apprendre". Ce debat se reproduit jusqu'à ce qu'on documente la contrainte : "pas d'expertise ops interne → managed services uniquement".

Inventaire des contraintes¶

Contraintes architecturales vs contraintes projet¶

Toutes les contraintes n'ont pas le même statut. Distinguer les contraintes architecturales (qui impactent la conception du système) des contraintes projet (qui impactent la manière de travailler) evite de melanger les discussions.

Les contraintes architecturales sont durables — elles survivent aux changements d'équipe. Les contraintes projet sont temporaires — une équipe peut apprendre Go, un budget peut être augmente. Cette distinction est importante pour la revue périodique des contraintes.

Comment découvrir les contraintes¶

Les contraintes ne sont pas toujours explicites. Elles s'extraient en posant les bonnes questions :

• Équipe : Combien de développeurs ? Quelles compétences ? Qui va opérer le système en production ?
• Budget : Quel est le budget infra mensuel ? Annuel ? Y a-t-il un budget initial différent du recurrent ?
• Temps : Quelle est la date de mise en production ? Negociable ou non ?
• Technique : Quels systèmes existants doivent être preserves ou intégrés ? Quelle stack est déjà maîtrisée ?
• Reglementaire : Quelles certifications ou conformites sont requises ? Dans quels secteurs ou pays le produit operera-t-il ?

Grille de découverte structurée¶

Lister les contraintes en début de projet remplacé des semaines de faux debats. Quand l'option "microservices" est éliminée par la taille de l'équipe, on ne la remet pas sur la table à chaque réunion.

Les contraintes ont un autre avantage : elles protègent les décisions prises. Quand un nouveau membre de l'équipe arrive avec de l'expérience sur Kubernetes et propose de migrer l'infrastructure, la contrainte budgetaire documentee met fin à la conversation avant qu'elle ne consomme de l'énergie collective.

Contraintes reglementaires détaillées¶

Les contraintes reglementaires meritent un traitement approfondi parce qu'elles sont non-negociables et que leur non-respect a des conséquences legales, pas seulement techniques.

RGPD (Reglement Général sur la Protection des Données)¶

Le RGPD s'applique dès que le système traite des données personnelles de residents europeens — quelle que soit la localisation du serveur.

PCI-DSS (Payment Card Industry Data Security Standard)¶

PCI-DSS s'applique à tout système qui traite, stocke ou transmet des données de carte bancaire.

HDS (Hebergement de Données de Sante)¶

La certification HDS est obligatoire en France pour tout hebergeur de données de sante a caractère personnel.

SOC 2¶

SOC 2 est un cadre d'audit americain base sur cinq principes : sécurité, disponibilité, intégrité du traitement, confidentialite et respect de la vie privee.

Journal de contraintes¶

Les contraintes evoluent au fil du projet. Une contrainte budgetaire peut être levee après une levee de fonds. Une contrainte reglementaire peut apparaître avec l'ouverture d'un nouveau marche. Documenter les contraintes dans un journal permet de tracer ces évolutions.

Le journal de contraintes complète les ADR. La ou l'ADR capture une décision ponctuelle, le journal capture les conditions de base qui orientent toutes les décisions. Quand on revoit un ADR d'il y a six mois, le journal de contraintes explique pourquoi les options etaient celles-la et pas d'autres.

graph TD
    CTX[Contrainte identifiee] --"documentee dans"--> LOG[Journal de contraintes]
    LOG --"oriente"--> DEC[Decisions architecture]
    DEC --"documentees dans"--> ADR[ADR]
    CTX --"change"--> REV[Revision]
    REV --"met a jour"--> LOG
    REV --"peut invalider"--> ADR

Negocier les contraintes¶

Toutes les contraintes ne sont pas gravees dans le marbre. Certaines sont negociables — et l'architecte a un rôle a jouer dans cette negociation.

Contraintes non-negociables :

• Reglementaires : RGPD, PCI-DSS, HDS → la loi ne se negocie pas
• Physiques : latence réseau entre continents → la physique ne se negocie pas
• Contractuelles : SLA envers les clients → engage la responsabilité juridique

Contraintes negociables :

• Budget : peut être augmente si le ROI est démontré
• Délai : peut être ajuste si le risque qualité est explicite
• Stack technique : peut évoluer si l'équipe est prete a investir en formation
• Équipe : peut être renforcee si le besoin est justifie

Pour negocier une contrainte, présenter l'impact en termes métier, pas techniques. "On a besoin de 500 EUR de plus par mois" ne fonctionne pas. "Avec 500 EUR de plus par mois, on divise le risque d'indisponibilite par trois, ce qui protégé un chiffre d'affaires mensuel de 50k EUR" fonctionne.

Technique de negociation : la matrice impact-effort¶

Pour chaque contrainte negociable, évaluer :

L'architecte n'est pas un negociateur professionnel, mais il est le mieux place pour quantifier l'impact technique d'une contrainte. Cette quantification est l'arme principale de la negociation.

Contraintes techniques implicites¶

Certaines contraintes ne figurent dans aucun document mais impactent fortement l'architecture. Elles s'extraient par l'observation et l'expérience.

Contraintes de l'écosystème¶

• Latence réseau : un appel inter-region ajoute 50-150ms. Un design qui enchaîné 5 appels synchrones cross-region impose 250-750ms de latence incompressible.
• Bande passante : un export de 10 GB quotidien vers un partenaire impose une réflexion sur le format, la compression et la fenêtre de transfert.
• DNS propagation : un basculement DNS prend 5 a 60 minutes selon les TTL. Si le RTO est de 15 minutes, le DNS failover ne suffit pas.

Contraintes organisationnelles cachees¶

Contraintes de dette technique¶

La dette technique existante est une contrainte a part entière. Un système legacy avec une base de données non normalisee, pas de tests automatises et un déploiement manuel impose des contraintes sur la vitesse d'évolution.

Documenter la dette technique comme contrainte — pas comme défaut — change la conversation. "Le système n'a pas de tests" est un reproche. "L'absence de tests automatises limite la vitesse de déploiement a une release par mois" est une contrainte documentee avec un impact mesurable.

Lien entre contraintes et décisions¶

Chaque contrainte documentee doit être liee aux décisions qu'elle influence. Cette traçabilité permet de réviser les décisions quand les contraintes changent.

Quand une contrainte est levee (par exemple, le budget passe a 2000 EUR/mois), la traçabilité indique quelles décisions peuvent être revisitees. Sans cette traçabilité, les anciennes contraintes continuent à influencer les choix par inertie.

Anti-patterns des contraintes¶

Chapitre suivant : TOGAF ADM — un cadre d'architecture d'entreprise pour les organisations qui ont besoin de structure.