⚡ OutSystems – High-Performance Low-Code, ALM & Gouvernance

Checklist de décision (10 questions)

Service Studio (dev)

Module:
- Public APIs (actions, structures)
- Private implementation
- No cross-layer shortcuts
- Errors standardisés
- Telemetry intégrée (corrId)
            

Service Center (ops)

Incident:
- identifier corrId / app / module
- vérifier erreur + contexte
- vérifier latence & ressources
- rollback release si nécessaire
- post-mortem (root cause + action)
            

LifeTime (ALM)

LifeTime:
- Environnements (DEV/QA/PROD…)
- Permissions / rôles
- Tag versions
- Déploiement “plan” + impact analysis
- Promotion contrôlée + rollback
        

Règles de dépendance (strictes)

UI -> Business (OK)
Business -> Core (OK)
Core -> Foundation (OK)
UI -> Core/Foundation (NO)
Core -> UI/Business (NO)
Foundation -> other layers (NO)
        

Expose:
- Server Actions (services)
- Structures/DTO
- Errors (codes)
Hide:
- tables internes
- helpers non stables
            

- éviter breaking changes
- ajouter champs plutôt que renommer
- déprécier (deprecated) avant suppression
            

Modules : industrialiser le “reuse”

Core modules (ex):
- CustomerCore
- OrderCore
- BillingCore

Foundation modules:
- LoggingFoundation
- AuthFoundation
- HttpFoundation
- CryptoFoundation
        

Anti-patterns (à interdire)

• UI qui appelle directement la DB / API externe (bypass des règles).
• Business logic copiée dans plusieurs écrans.
• Modules “god” : tout dedans, rien réutilisable.
• Erreurs non standardisées : debugging impossible à grande échelle.

Règle d’or :
Tous les side-effects (DB/HTTP) passent par Core/Foundation via Business.
        

Contrat API standard (à imposer)

Response:
{
  "status": "ok|error",
  "data": {...},
  "error": { "code": "...", "message": "...", "corrId": "..." }
}

Paging:
{
  "items": [...],
  "page": 1,
  "size": 50,
  "total": 1234
}
        

- OAuth2/JWT (si disponible)
- RBAC côté plateforme + checks métier
- audit actions sensibles
            

Erreurs : “user message” vs “tech message”

User:  "Email déjà utilisé"
Tech:  "Unique constraint Customer.Email violated"
Logs:  corrId + user + module + usecase + latency
        

Versioning API (pragmatique)

Option A: /api/v1/...
Option B: header version
Option C: "additive only" + deprecation

Règles:
- ajouter champs (safe)
- ne pas renommer brutalement
- déprécier -> monitor -> supprimer
        

Validation : 3 niveaux

Niveau 1 UI: required, formats simples
Niveau 2 Business: règles métier (droits, workflow)
Niveau 3 Data: contraintes (unique, FK, tx)
        

State : éviter “l’état fantôme”

State stable :
- DTO unique pour écran
- load() centralisé
- actions => update(dto) => refresh view
- erreurs standardisées + corrId
        

Accessibilité (minimum sérieux)

• Labels explicites + focus visible.
• Navigation clavier (Tab order).
• Contrastes OK et erreurs annoncées.
• Messages non uniquement couleur.

Secrets : jamais dans le code

• Config par environnement (DEV/QA/PROD).
• Rotation + moindre privilège.
• Logs “safe” : pas de PII/tokens en clair.

OWASP : minimum vital

• Validation server-side (toujours).
• Prévenir injection (requêtes paramétrées / APIs propres).
• CSRF / session policies (selon mode).
• Headers sécurité (HSTS/CSP) si applicable.

Audit : traçabilité “industrial grade”

Audit event:
- who (user)
- what (action)
- where (module/usecase)
- when (timestamp)
- correlationId
- payload metadata (not full PII)
        

Tagging : version “promouvable”

Principe :
- créer une version taguée
- promouvoir cette version entre envs
- garder historique & traçabilité release
        

Déploiement : plan + impact analysis

Deploy plan:
- sélectionner apps/modules
- analyser impact (dépendances)
- exécuter la promotion
- vérifier health + smoke tests
        

Rollback : 3 niveaux

N1: rollback app (revenir release précédente)
N2: rollback config (feature flag off)
N3: rollback data (restore snapshot / scripts)
        

Gouvernance : qui a le droit de quoi

Roles (ex):
- Developer: build DEV
- QA: validate + report
- Release manager: promote to PROD
- Ops: runtime + monitoring
        

Dette technique : ce que tu dois mesurer

Vue portfolio : le vrai gain en enterprise

Tu veux pouvoir répondre :
- quelles apps sont critiques ?
- où sont les dépendances dangereuses ?
- quels modules sont “hot spots” ?
- quelle dette bloque la roadmap ?
        

Plan d’action “pratique”

1. Fixer conventions (4-layer, naming, APIs, errors).
2. Mesurer baseline (dette + hotspots).
3. Refactor “top 10” (ce qui rapporte le plus).
4. Mettre gate qualité avant PROD.
5. Suivre KPI : lead time, incidents, rollback rate.

Artifacts (ce qu’on archive)

Tests “qui rapportent” (coût/valeur)

• Smoke : login + parcours critique.
• Data integrity : create/update sur entités clé.
• Perf : latence endpoints majeurs sous seuil.
• Security : RBAC sur actions sensibles.

Gates avant PROD :
- 0 blockers
- smoke OK
- KPI perf OK
- rollback plan ready
        

Promotion : discipline release

Promotion rules:
- tag unique
- promotion contrôlée
- pas de changements manuels en PROD
- monitoring renforcé 24-48h
        

Runbook déploiement (à copier/coller)

Pre:
- backup/snapshot (si data change)
- release notes validées
- fenêtres & owner incident

Deploy:
- promote
- healthcheck
- smoke tests

Post:
- monitor (errors, latency)
- rollback si seuils dépassés
- post-mortem si incident
        

Data perf : erreurs classiques

Keyset pagination:
WHERE (CreatedAt, Id) < (:lastCreatedAt, :lastId)
ORDER BY CreatedAt DESC, Id DESC
LIMIT :size
        

Cache : où ça marche vraiment

Observabilité (KPI)

KPI:
- p95 latency (top endpoints)
- error rate (4xx/5xx)
- rollback rate
- incident MTTR
- deploy frequency / lead time
        

Carte de choix

Besoin enterprise + ALM + multi-apps + reuse  -> OutSystems
Besoin desktop Windows CRUD rapide             -> WinDev
Besoin M365 / governance Microsoft             -> Power Apps
Besoin contrôle total, cloud-native, OSS       -> code-first (Django/Spring/.NET/Node)
        

Risques & mitigations

Playbook “lancement programme” (10 jours)

1. Définir conventions (4-layer, naming, errors, paging).
2. Créer modules foundation (log, auth, http, crypto).
3. Créer core domain minimal (customer/order).
4. Mettre pipeline DEV→QA→PROD + tagging.
5. Mettre smoke tests + rollback plan.
6. Activer suivi dette (AI Mentor) + KPI.
7. Onboard équipe (do/don’t + templates).