Passer au contenu principal

Gouvernance et bonnes pratiques

BBC-Partners Solutions - Direction Innovation et Technologie

1. Gouvernance de la DIT

1.1 Instances de gouvernance

Instance Fréquence Participants Objectifs
Comité de direction Mensuel Directeur DIT, CEO Stratégie, budget, ressources
Comité technique Mensuel Directeur DIT, Resp. pôles Architecture, standards, outillage
Réunion DIT Mensuel Toute la DIT Communication, cohésion
Point DIT-DPS Bi-mensuel Directeurs DIT et DPS Coordination, arbitrages

1.2 Processus de décision

Décisions stratégiques

  • Choix d'architecture majeurs
  • Adoption de nouvelles technologies
  • Investissements significatifs
  • Recrutements

Processus : Proposition → Analyse → Validation Directeur DIT → Validation CEO (si impact budgétaire)

Décisions techniques

  • Choix de librairies
  • Patterns de développement
  • Standards de codage

Processus : Proposition → Discussion Comité technique → Validation Directeur DIT

Décisions opérationnelles

  • Répartition des tâches
  • Priorisation des sprints
  • Résolution de problèmes quotidiens

Processus : Discussion équipe → Décision Resp. pôle ou Scrum Master

1.3 Documentation des décisions

Toute décision structurante doit être documentée avec :

  • Date de la décision
  • Contexte et problématique
  • Options envisagées
  • Décision retenue et justification
  • Participants à la décision

2. Conventions de nommage

2.1 Nommage du code

Variables et fonctions

Langage Convention Exemple
JavaScript/TypeScript camelCase getUserName(), isActive
Python snake_case get_user_name(), is_active
PHP camelCase (méthodes), snake_case (variables) getUserName(), $user_name
CSS kebab-case .user-profile, .btn-primary

Classes et composants

Langage Convention Exemple
JavaScript/TypeScript PascalCase UserProfile, DataService
Python PascalCase UserProfile, DataService
PHP PascalCase UserProfile, DataService

Constantes

Langage Convention Exemple
Tous UPPER_SNAKE_CASE MAX_RETRY_COUNT, API_BASE_URL

2.2 Nommage des fichiers

Type Convention Exemple
Composants React PascalCase.jsx/tsx UserProfile.tsx
Modules Python snake_case.py user_service.py
Fichiers PHP PascalCase.php UserController.php
Fichiers CSS kebab-case.css user-profile.css
Tests *.test.js ou *_test.py user.test.js, user_test.py

2.3 Nommage Git

Branches

Type Convention Exemple
Feature feature/[ticket]-description feature/MTX-123-ajout-filtre-date
Bugfix bugfix/[ticket]-description bugfix/MTX-456-correction-calcul-tva
Hotfix hotfix/[ticket]-description hotfix/MTX-789-fix-connexion
Release release/vX.Y.Z release/v2.1.0

Commits

Format : [type]: [description courte]

Type Usage Exemple
feat Nouvelle fonctionnalité feat: ajout filtre par date
fix Correction de bug fix: correction calcul TVA
docs Documentation docs: mise à jour README
style Formatage (pas de changement fonctionnel) style: formatage du code
refactor Refactoring refactor: extraction service utilisateur
test Ajout ou modification de tests test: ajout tests unitaires login
chore Maintenance chore: mise à jour dépendances

Règles :

  • Message en français ou anglais (cohérence par projet)
  • Première ligne ≤ 72 caractères
  • Description détaillée si nécessaire (après ligne vide)
  • Référence au ticket si applicable

2.4 Nommage des bases de données

Élément Convention Exemple
Tables snake_case, pluriel users, work_orders
Colonnes snake_case created_at, user_id
Clés primaires id id
Clés étrangères [table]_id user_id, equipment_id
Index idx_[table]_[colonnes] idx_users_email

3. Standards de qualité du code

3.1 Principes généraux

Principe Description
Lisibilité Le code doit être compréhensible sans documentation excessive
Simplicité Préférer les solutions simples aux solutions complexes
DRY Don't Repeat Yourself - Éviter la duplication
SOLID Principes de conception orientée objet
Tests Tout code doit être testé

3.2 Couverture de tests

Type de code Couverture minimale
Code métier critique 80%
Code métier standard 70%
Utilitaires 60%
Code UI 50%

3.3 Revue de code

Critères de validation :

Critère Description
Fonctionnalité Le code répond au besoin
Tests Tests présents et pertinents
Lisibilité Code clair et bien structuré
Conventions Respect des conventions de nommage
Performance Pas de problème de performance évident
Sécurité Pas de faille de sécurité
Documentation Commentaires pertinents si nécessaire

Processus :

  1. Le développeur crée une Pull Request (PR)
  2. Au moins un relecteur examine le code
  3. Les commentaires sont traités
  4. La PR est approuvée et mergée

3.4 Dette technique

Gestion :

  • Identifier et documenter la dette technique
  • Prioriser le remboursement selon l'impact
  • Allouer du temps dans chaque sprint (environ 20%)
  • Mesurer l'évolution de la dette

4. Sécurité

4.1 Principes de sécurité

Principe Application
Moindre privilège Accès minimum nécessaire
Défense en profondeur Plusieurs couches de protection
Sécurité par conception Intégrer la sécurité dès la conception
Validation des entrées Ne jamais faire confiance aux données externes

4.2 Bonnes pratiques de développement sécurisé

Catégorie Pratiques
Authentification Mots de passe hashés, tokens sécurisés, MFA si sensible
Autorisation Contrôle d'accès basé sur les rôles (RBAC)
Données Chiffrement des données sensibles, pas de données en clair
Communications HTTPS obligatoire, validation des certificats
Injection Requêtes paramétrées, validation des entrées
XSS Échappement des sorties, Content Security Policy
CSRF Tokens CSRF, vérification de l'origine

4.3 Gestion des secrets

Secret Stockage Accès
Mots de passe BDD Variables d'environnement DevOps, Directeur DIT
Clés API Gestionnaire de secrets Selon besoin
Certificats Gestionnaire de secrets DevOps
Tokens Variables d'environnement Application uniquement

Règles :

  • Jamais de secrets dans le code source
  • Jamais de secrets dans les logs
  • Rotation régulière des secrets
  • Accès tracé et audité

4.4 Gestion des vulnérabilités

Action Fréquence Responsable
Scan des dépendances À chaque build (CI) Automatique
Revue des alertes de sécurité Hebdomadaire Resp. pôle Backend
Mise à jour des dépendances Mensuelle Équipe de développement
Audit de sécurité Annuel Externe ou Directeur DIT

5. Documentation technique

5.1 Documentation obligatoire

Type Contenu Responsable
README Installation, configuration, démarrage Développeur
Architecture Schémas, choix techniques Resp. pôle
API Endpoints, paramètres, réponses (Swagger) Développeur Backend
Base de données Modèle de données, relations Développeur Backend
Déploiement Procédures, environnements DevOps

5.2 Format de la documentation

  • Format : Markdown (.md) pour la documentation textuelle
  • Schémas : Draw.io, Mermaid, ou PlantUML
  • API : OpenAPI/Swagger
  • Emplacement : Dans le dépôt Git du projet (dossier /docs)

5.3 Mise à jour

  • La documentation est mise à jour en même temps que le code
  • Les PR incluent la mise à jour de la documentation si nécessaire
  • Revue de la documentation lors des revues de code

6. Indicateurs de performance (KPI)

6.1 KPI de production

Indicateur Définition Cible Fréquence
Vélocité Story points livrés par sprint Stable ou croissante Sprint
Lead time Temps entre demande et livraison < 2 sprints Mensuel
Cycle time Temps de développement effectif < 5 jours/story Sprint
Taux de livraison Stories livrées vs engagées ≥ 90% Sprint

6.2 KPI de qualité

Indicateur Définition Cible Fréquence
Couverture de tests % du code couvert par des tests ≥ 70% Build
Bugs en production Nombre de bugs détectés en prod ≤ 2/sprint Sprint
Dette technique Ratio dette/code < 5% Mensuel
Taux de réouverture Bugs réouverts après correction < 10% Mensuel

6.3 KPI de disponibilité

Indicateur Définition Cible Fréquence
Disponibilité Uptime des applications ≥ 99.5% Mensuel
MTTR Temps moyen de résolution < 4h (critique) Incident
Incidents critiques Nombre d'incidents P1 ≤ 1/mois Mensuel

6.4 Tableau de bord

Un tableau de bord consolidant ces KPI est mis à jour mensuellement et partagé avec :

  • Le CEO (rapport mensuel)
  • La DPS (indicateurs projets)
  • L'équipe DIT (réunion mensuelle)

7. Réunions de gouvernance

7.1 Comité technique mensuel

Attribut Valeur
Fréquence 1er mardi du mois
Durée 2 heures
Participants Directeur DIT, Responsables de pôle
Animateur Directeur DIT

Ordre du jour type :

  1. Revue des KPI (15 min)
  2. Points techniques en cours (30 min)
  3. Décisions architecturales à prendre (30 min)
  4. Veille technologique (15 min)
  5. Retour d'expérience (15 min)
  6. Questions diverses (15 min)

7.2 Réunion DIT mensuelle

Attribut Valeur
Fréquence 3ème vendredi du mois
Durée 1 heure
Participants Toute l'équipe DIT
Animateur Directeur DIT

Ordre du jour type :

  1. Actualités de l'entreprise (10 min)
  2. Bilan du mois écoulé (15 min)
  3. Projets à venir (15 min)
  4. Partage de connaissances (15 min)
  5. Questions / Suggestions (5 min)

8. Amélioration continue

8.1 Sources d'amélioration

Source Fréquence Traitement
Rétrospectives de sprint Bi-hebdomadaire Actions intégrées au sprint suivant
Retours DPS Continu Analyse et priorisation
Incidents Continu Post-mortem et actions correctives
Veille technologique Continu Évaluation et adoption si pertinent

8.2 Processus d'amélioration

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  IDENTIFIER  │───▶│   ANALYSER   │───▶│  IMPLÉMENTER │───▶│   MESURER    │
│              │    │              │    │              │    │              │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
       ▲                                                            │
       └────────────────────────────────────────────────────────────┘
                              Boucle continue

8.3 Capitalisation

Action Description
Base de connaissances Documentation des solutions et bonnes pratiques
Retours d'expérience REX formalisés après chaque projet significatif
Formation interne Partage de connaissances entre collaborateurs
Veille partagée Diffusion des découvertes technologiques

Documents connexes

Document maintenu par la DIT - BBC-Partners Solutions

Aucun commentaire à afficher

Retour en haut