🎴 Article 2: L'Axe Y - Visibilité (Visible → Invisible)

🎯 Vue d’Ensemble

Cet article répond à la question: Qui voit cet élément?

🔴 IMPORTANT - NOUVEL ORDRE PÉDAGOGIQUE:

  • ✅ Vous lisez cet article EN SECOND (après Article 1: Concepts)
  • ✅ Axe Y se fait AVANT Axe X (pas l’inverse!)
  • ✅ Pourquoi? Axe Y = comprendre les dépendances VERTICALES
  • ✅ Puis: Axe X applique l’évolution à cette structure

L’axe Y montre:

  • ✅ Si un élément est visible aux clients/utilisateurs (haut) ou invisible en arrière-plan (bas)
  • ✅ Niveau de conscience utilisateur de ce composant
  • ✅ Impact direct vs indirect sur l’expérience utilisateur
  • ✅ Où placer frontends, services supports, infrastructures
  • ✅ DÉPENDANCES VERTICALES (qui dépend de qui verticalement)

Durée d’apprentissage: 20-25 minutes
Niveau: Débutant (après Article 1)
Prérequis: Aucun (mais lire Concepts d’abord)
Lire avant: Article 3 (Axe X)

📊 L’Axe Y Expliqué

Le Principe Simple

HAUT (VISIBLE)        
│ Utilisateur voit & interagit directement
│
├─ App Frontend
├─ User Interface
├─ Features utilisateur
│
├─ (Limite de visibilité)
│
├─ Backends
├─ Services
├─ Caches
│
BAS (INVISIBLE)
└─ Infrastructure physique
  └─ Électricité, réseau, données centers...

3 Niveaux de Visibilité (axe Y)

Niveau Position Caractéristique Exemple
HAUT Visible Client voit et interagit App mobile, website
MILIEU Semi-visible Utilisateur peut sentir l’impact Backend services, payment
BAS Invisible Client ne voit jamais Électricité, serveurs physiques

👁️ Zone 1: Visible (En Haut)

Qu’est-ce qu’une “Zone Visible”?

C’est tout ce que l’utilisateur voit et peut directement interagir avec:

Exemples: 
  ✓ Interface utilisateur (buttons, pages)
  ✓ Features (upload, search, checkout)
  ✓ Workflow utilisateur (login → browse → buy)
  ✓ Notifications (emails, pop-ups)

Caractéristiques Zone Visible

Aspect Caractéristique
Conscience utilisateur ✓ 100% conscient
Interactivité ✓ Interaction directe possible
Impact ressenti ✓ Impacte directement satisfaction
Feedback ✓ Feedback utilisateur direct & immédiat
Importance marketing ✓ TRÈS importante pour branding

Exemples Zone Visible

Netflix (Visible)

👁️ HAUT (Visible):
  ├─ App mobile (interface principale)
  ├─ Homepage personnalisée
  ├─ Search bar
  ├─ Play button
  ├─ User profiles
  ├─ Settings page
  └─ Subscription UI
  
Utilisateur voit TOUT ça
Utilisateur clique, tape, swipe, clique play...

Amazon (Visible)

👁️ HAUT (Visible):
  ├─ Homepage produits
  ├─ Product pages
  ├─ Shopping cart
  ├─ Checkout flow
  ├─ Order tracking
  ├─ Reviews section
  └─ Personalized recommendations
  
Client INTERAGIT avec ces éléments
Client juge le service sur cette visibilité

Stratégie Visible

Investir massivement en UX/UI:

  • ✓ User research & testing
  • ✓ Design excellence
  • ✓ Performance perçue (speed felt by user)
  • ✓ Accessibility
  • ✓ A/B testing continu

Impact: Visible = directement convertit en satisfaction/fidélité/revenu

🔧 Zone 2: Semi-Visible (Au Milieu)

Qu’est-ce que “Semi-Visible”?

Services qui existent mais utilisateur les utilise indirectement:

Utilisateur ne les voit pas directement
Mais les impacts sur l'expérience sont apparents
Exemple: Payment gateway (utilisateur sait qu'il paye, mais ne voit pas API)

Caractéristiques

Aspect Caractéristique
Conscience directe ~ 30-70% conscient
Interactivité ✓ Interaction indirecte (via autre élément)
Impact ressenti ✓ Impacte via frontend
Feedback ✓ Indirect (travers d’erreurs, delays)

Exemples

Élément Pourquoi Semi-Visible? Manifestation
Payment API Utilisateur paye mais ne voit pas API ✓ Voit “Payment successful”
Notification service Envoie emails/SMS invisiblement ✓ Reçoit messages
User Auth Utilisateur se log mais ne voit pas auth system ✓ Ça marche ou ça marche pas
Search backend Utilisateur tape “Star Wars” ✓ Résultats apparaissent (magic!)
Cache layer Performance boost invisible ✓ Sent que ça va vite

Stratégie Semi-Visible

Optimiser transparence & impact:

  • ✓ Monitoring de performance
  • ✓ Error handling graceful (si ça casse, utilisateur sait pourquoi)
  • ✓ Reliability (99.9% uptime)
  • ✓ Performance backends

Règle d’Or: Si semi-visible casse → visible se casse aussi

Semi-Visible ← dépendance → Visible
     ↓
  Payment API casse
     ↓
  Checkout fails
     ↓
  Customer angry

⚙️ Zone 3: Invisible (En Bas)

Qu’est-ce qu’“Invisible”?

Infrastructure physique et services dont utilisateur n’est jamais conscient:

Exemples:
  ✓ Électricité
  ✓ Connexion réseau physique
  ✓ Data centers
  ✓ Serveurs physiques
  ✓ Disques durs
  ✓ Câbles de fibre optique

Caractéristiques

Aspect Caractéristique
Conscience utilisateur ✗ 0% conscient (sauf panne!)
Interactivité ✗ Zéro interaction possible
Manifestation = Absence = “ça marche”
Feedback ✓ Feedback SEULEMENT si ça casse
Importance marketing ✗ ZÉRO (invisible)

Exemples Invisibles

Élément Raison Implication
Électricité Utilisateur n’a jamais pensé à comment l’app marche Panne = app muet
Fiber réseau Utilisateur juste “use” l’app Coupure = app down
Data center Utilisateur aucune conscience Disaster = 0 service
Serveurs AWS Utilisateur sait “AWS exists” mais ne le touche pas C’est derrière les scenes
Database physique Utilisateur jamais conscient Mais crash = app crash

Stratégie Invisible

Fiabilité absolue & coûts minimaux:

  • ✓ SLA 99.99% uptime
  • ✓ Redundancy & failover
  • ✓ Disaster recovery
  • ✓ Minimiser coûts (pas de différenciation possible)

Paradoxe: Plus invisible = plus important en stabilité

Invisible casse → Tout le système casse
Visible casse → Juste cette feature est down

🔗 Concept: Dépendances Verticales

Comment Ça Dépend Verticalement

HAUT (VISIBLE)
│
│ App UI (utilisateur clique)
│   │
│   ├─ dépend de ↓
│   │
│   ▼
MILIEU (SEMI-VISIBLE)
│
│ Backend API (process request)
│   │
│   ├─ dépend de ↓
│   │
│   ▼
BAS (INVISIBLE)
│
│ Infrastructure (électricité, réseau)
│
└─ ← Si ça casse, tout casse

Règle Critique: Chaîne Verticale

Élément visible dépend TOUJOURS d’éléments plus invisibles:

UI dépend de Backend
Backend dépend de Database
Database dépend de Électricité & Réseau

Implication stratégique:

Si infrastructure invisible casse → tout visible tombe
Si backend casse → UI devient inutile
Si UI casse → utilisateur voit erreur

📍 Positionnement Pratique: Haut vs Bas?

Règle de Décision Simple

EN HAUT (Visible) si:

  • ✓ Utilisateur voit cet élément
  • ✓ Utilisateur interagit avec
  • ✓ Marketing/branding importance
  • ✓ UX/UI concerns
  • ✓ Feedback utilisateur direct

AU MILIEU (Semi-Visible) si:

  • ✓ Utilisateur n’interagit pas directement
  • ✓ Mais impact indirect sur expérience
  • ✓ Panne = problème apparent
  • ✓ Service backend, processing, validation

EN BAS (Invisible) si:

  • ✓ Utilisateur jamais conscient
  • ✓ Complètement arrière-plan
  • ✓ Infrastructure physique
  • ✓ Existe SEULEMENT pour faire marcher le système

Exemples Décisifs

Élément Position Justification
Netflix App UI ⬆️ Haut Utilisateur voit, clique, interagit
Recommendation Engine ⬆️ Haut/Milieu Utilisateur voit résultats, pas le moteur
Payment Processing ↔️ Milieu Utilisateur sait qu’il paye, pas les détails
Database ⬇️ Bas Utilisateur jamais conscient
Électricité ⬇️ Bas Complètement invisible
AWS Servers ⬇️ Bas Infrastructure arrière-plan

🎯 Dépendances Haut↔Bas

Cas d’Étude: Netflix

HUT (VISIBLE):
│ App UI
│ ├─ Browse page
│ ├─ Play button
│ ├─ Search box
│ └─ Profiles
│     │
│     └─ dépend de ↓
│
MILIEU:
│ Backend services
│ ├─ User service
│ ├─ Streaming API
│ ├─ Recommendation API
│ ├─ Payment verification
│ └─ Search service
│     │
│     └─ dépend de ↓
│
BAS (INVISIBLE):
│ Infrastructure
│ ├─ AWS EC2 (servers)
│ ├─ S3 storage (videos)
│ ├─ ElasticSearch (search index)
│ ├─ RDS databases
│ └─ CDN edge nodes
│     │
│     └─ dépend de ↓
│
│ Commodity Infrastructure
│ ├─ Électricité
│ ├─ Réseau physique
│ └─ Internet backbone

Dépendances Critiques

Si une dépendance BAS casse:

  • ❌ Électricité casse → Tout netflix down
  • ❌ Réseau casse → Impossible streaming
  • ❌ AWS casse → Impossible requêtes

Puis dépendances MILIEU casse:

  • ❌ Backend API down → UI peut plus récupérer data
  • ❌ Payment service down → Plus de checkout possible

Puis visible se casse:

  • ❌ UI marche mais affiche “Error loading”
  • ❌ Utilisateur voit rien → pas content

🚨 Erreurs Courantes: Positionnement Axe Y

Erreur 1: Mettre Infrastructure en Haut

❌ MAUVAIS:
   ⬆️ AWS Servers (en Haut/Visible)
   → Mais utilisateurs jamais pensent à AWS!
   
✓ BON:
   ⬇️ AWS Servers (en Bas/Invisible)
   → Infrastructure arrière-plan

Erreur 2: Mettre UI en Bas

❌ MAUVAIS:
   ⬇️ App UI (en Bas/Invisible)
   → Mais c'est TOUT ce que l'utilisateur voit!
   
✓ BON:
   ⬆️ App UI (en Haut/Visible)

Erreur 3: Oublier Dépendances Verticales

❌ MAUVAIS:
   ⬆️ App (sans dépendances)
   → Ça existe dans le vide!
   
✓ BON:
   ⬆️ App
     │
     ├─ dépend de ↓
     │
   ↔️ Backend APIs
     │
     ├─ dépend de ↓
     │
   ⬇️ AWS Infrastructure

💡 Insights Stratégiques: Axe Y

Insight 1: Visibilité = Feedback Utilisateur

⬆️ HAUT (Visible):
   ★ = Utilisateur feedback direct
   → UX/UI = top priority
   → A/B testing tout
   → Design iteration rapide
   
⬇️ BAS (Invisible):
   ♦ = Zéro feedback utilisateur
   → Efficiency = top priority
   → Monitoring & alerting
   → Reliability > fancy features

Insight 2: Chaîne de Confiance Verticale

Utilisateur confiance APP (visible)
  ↓ dépend de
Utilisateur implicite confiance BACKEND (semi-visible)
  ↓ dépend de
Utilisateur jamais pense à INFRASTRUCTURE (invisible)
  ↓
Mais infrastructure FAILS?
  ↑ = TOUT tombe

Implication: Invisible est PLUS critique que Visible!

Insight 3: Support Strategy par Niveau

⬆️ VISIBLE:
   = Direct customer support
   = Chatbots, help docs, FAQ
   = Training users
   
↔️ SEMI-VISIBLE:
   = Monitoring & alerting
   = Dev team on-call
   = Incident response
   
⬇️ INVISIBLE:
   = Infrastructure SRE team
   = Redundancy & failover
   = Disaster recovery planning

🎯 Exercice 1: Netflix Positionnement Axe Y

Tâche: Positionner Chaque Élément

Éléments à classer:

  1. Netflix App (iOS/Android)
  2. Browse & Search UI
  3. Play button & video player
  4. User authentication
  5. Recommendation algorithm backend
  6. Streaming API
  7. Video storage (S3)
  8. Database utilisateurs
  9. CDN nodes
  10. Électricité datacenter

Solution:

⬆️ HAUT (VISIBLE):
   1 Netflix App
   2 Browse & Search UI
   3 Play button & video player
   4 (Some auth visible - login form)
       │
       └─ dépend de ↓

↔️ MILIEU (SEMI-VISIBLE):
   4 User authentication (backend)
   5 Recommendation algorithm (résultats visibles)
   6 Streaming API
       │
       └─ dépend de ↓

⬇️ BAS (INVISIBLE):
   7 Video storage (S3)
   8 Database utilisateurs
   9 CDN nodes
  10 Électricité datacenter

🎯 Exercice 2: Votre Contexte

Défi: Cartographier Votre Produit Axe Y

Instructions:

  1. Lister 10-15 éléments
  2. Classer haut/milieu/bas selon visibilité
  3. Identifier dépendances verticales
  4. Identifier points critiques invisibles
  5. Planifier support pour chaque niveau

Exemple: E-commerce

⬆️ HAUT (VISIBLE):
├─ Product pages
├─ Search box
├─ Shopping cart
├─ Checkout flow
└─ Order confirmation
   │
   └─ dépend de ↓

↔️ MILIEU (SEMI-VISIBLE):
├─ Payment processor
├─ Inventory checker
├─ Order database queries
└─ Email notifications
   │
   └─ dépend de ↓

⬇️ BAS (INVISIBLE):
├─ AWS servers
├─ S3 storage
├─ Database servers
└─ Réseau infrastructure

📊 Résumé: Axe Y en 1 Page

Dimension Caractéristique
Haut (Visible) Utilisateur voit & interagit, feedback direct
Milieu (Semi-Visible) Services backend, impact indirect
Bas (Invisible) Infrastructure, arrière-plan 100%
Dépendances Toujours haut dépend de bas
Critique Bas = plus critique (si casse, tout casse)
Support UX design pour visible, reliability pour invisible

🏆 Points à Retenir: Axe Y

✅ EN HAUT = Visible

  • Utilisateur voit & interagit
  • UX/UI importance critique
  • Feedback utilisateur direct
  • Branding & satisfaction

✅ AU MILIEU = Semi-Visible

  • Services backend
  • Utilisateur sent l’impact indirect
  • Monitoring importance critique
  • Reliability > fancy

✅ EN BAS = Invisible

  • Infrastructure physique
  • Utilisateur jamais conscient
  • Fiabilité absolue nécessaire
  • Coût optimization focus

✅ DÉPENDANCES VERTICALES

  • Visible dépend de semi-visible
  • Semi-visible dépend d’invisible
  • Si invisible casse → tout casse
  • Paradox: plus invisible = plus critique

✅ SUPPORT STRATEGY

  • Visible: UX research, A/B testing, support clients
  • Semi-visible: Monitoring, alerting, incident response
  • Invisible: SRE, redundancy, disaster recovery

📚 Prochaines Étapes

Vous maîtrisez maintenant les 2 axes! 🎉

Axe X: Innovation → Commodité (horizontalement)
Axe Y: Visible → Invisible (verticalement)

Prochaine étape: Combiner les 2 axes!

➡️ Aller à l’article 4: Mouvements Stratégiques →

Ou voir comment ça s’applique: ➡️ Cas Netflix →

Créé: 2025-11-17
Carte: 3/5 (Axe Y)
Niveau: Débutant
Durée: 20-25 minutes