Tests, Sécurité et CI/CD

Cet article présente une stratégie pour assurer la qualité, la sécurité et le déploiement continu d’une application basée sur Laravel 11 et React 18. La stratégie s’articule autour de quatre piliers fondamentaux :

1. Tests complets et modernes : Une approche multi-niveaux incluant des tests unitaires, d’intégration, de sécurité et de performance, en utilisant les outils modernes de 2025 comme Pest pour Laravel et Vitest pour React.
2. Sécurité par conception (DevSecOps) : Intégration des tests de sécurité dès les premières phases du développement, couvrant l’OWASP Top 10 2023, la conformité RGPD, et utilisant des outils automatisés pour détecter les vulnérabilités.
3. Pipeline CI/CD optimisé : Utilisation de GitHub Actions avec des matrices de test pour une exécution parallèle, caching des dépendances, et un déploiement automatisé vers des environnements multiples (test, staging, production).
4. Infrastructure moderne et observabilité : Adoption de Docker pour la conteneurisation, Infrastructure as Code avec Terraform, et mise en place de monitoring et alertes pour assurer la performance et la fiabilité de l’application.

Cette stratégie permet de détecter les problèmes au plus tôt dans le cycle de développement (approche “shift-left”), réduisant ainsi les coûts de correction et accélérant les cycles de livraison tout en maintenant un haut niveau de qualité et de sécurité.

• Backend : Laravel 11 (version correcte, sortie en mars 2024)
• Frontend : React 18 (correction de React 19 qui n’existe pas encore)
• Base de données : MySQL
• Hébergement : O2Switch ou alternatives cloud (AWS, GCP, Azure)
• Philosophie DevOps : Automatisation, intégration continue, tests de sécurité précoce, infrastructure as code

Objectifs

1. Assurer la fiabilité via des tests approfondis (unitaires, intégration, E2E, sécurité, performance)
2. Automatiser le pipeline pour déployer rapidement via des approches GitOps
3. Mettre en place des environnements conteneurisés pour une plus grande cohérence (dev, test, staging, prod)
4. Intégrer la sécurité à toutes les étapes (DevSecOps) selon l’OWASP 2023 Top 10
5. Assurer la conformité RGPD et autres réglementations pertinentes

2. Stratégie de Tests

2.1 Introduction à la Stratégie de Tests

La qualité logicielle repose sur une stratégie de tests complète couvrant tous les aspects de l’application. les tests automatisés sont devenus un standard incontournable, avec une approche “shift-left” qui intègre les tests dès les premières étapes du développement.

Nouveaux objectifs

• Obtenir une couverture de tests d’au moins 80% sur le code critique
• Intégrer les tests de performance dès les phases précoces (shift-left performance testing)
• Mettre en place des tests de compatibilité cross-browser automatisés
• Implémenter des tests d’accessibilité WCAG 2.2

2.2 Tests Unitaires Backend

2.2.1 Configuration des outils de test

Laravel 11 offre désormais deux options principales pour les tests unitaires :

Option 1: PHPUnit (approche traditionnelle)

composer require --dev phpunit/phpunit

Option 2: Pest (recommandé )

composer require --dev pestphp/pest
php artisan pest:install

Pest est une évolution moderne de PHPUnit qui offre une syntaxe plus expressive et lisible :

// Exemple de test avec Pest
test('user can be created', function () {
    $user = User::factory()->create();
    
    expect($user)->toBeInstanceOf(User::class);
    expect($user->id)->toBeInt();
});

// Groupes de tests avec Pest
describe('User creation', function () {
    test('creates with valid data', function () {
        // Test logique
    });
    
    test('fails with invalid email', function () {
        // Test logique
    });
});

2.2.2 Tests des Modèles

Les tests de modèles vont au-delà des simples relations :

// Test de factory avec état
test('user with admin status has admin role', function () {
    $user = User::factory()->admin()->create();
    
    expect($user->isAdmin())->toBeTrue();
    expect($user->roles->contains('name', 'admin'))->toBeTrue();
});

// Test de méthodes de modèle
test('getTotalSpentAttribute calculates correctly', function () {
    $user = User::factory()->create();
    Order::factory()->count(3)->create([
        'user_id' => $user->id,
        'amount' => 100
    ]);
    
    expect($user->total_spent)->toBe(300);
});

2.2.3 Tests des Services

Les services doivent être testés de manière isolée avec injection de dépendances :

// Utilisation de mocks avec Pest et Laravel
test('payment service charges correctly', function () {
    // Créer un mock du gateway de paiement
    $gateway = mock(PaymentGatewayInterface::class);
    
    // Configurer les attentes
    $gateway->shouldReceive('charge')
        ->once()
        ->with(100, 'USD')
        ->andReturn(['status' => 'success', 'transaction_id' => 'tx_123']);
    
    // Injecter le mock dans le service
    $service = new PaymentService($gateway);
    
    // Exécuter et vérifier
    $result = $service->charge(100, 'USD');
    expect($result->status)->toBe('success');
    expect($result->transaction_id)->toBe('tx_123');
});

2.2.4 Mocks, Stubs et Fakes

Laravel 11 offre plusieurs options pour isoler les tests

// Fake de service natif Laravel
test('mail is sent', function () {
    // Intercepter les emails
    Mail::fake();
    
    // Exécuter le code qui envoie un email
    (new OrderService())->processOrder($order);
    
    // Vérifier l'envoi
    Mail::assertSent(OrderConfirmation::class, function ($mail) use ($order) {
        return $mail->order->id === $order->id;
    });
});

// Stubbing de réponse HTTP (nouveauté Laravel 11)
test('api client handles server error', function () {
    Http::fake([
        'api.example.com/*' => Http::response(['error' => 'Server error'], 500)
    ]);
    
    $client = new ApiClient();
    
    // Vérifier la gestion d'erreur
    expect(fn() => $client->fetchData())->toThrow(ApiException::class);
});

2.3 Tests Unitaires Frontend

2.3.1 Configuration des Outils Modernes

les outils de test frontend ont considérablement évolué :

Vitest (alternative moderne à Jest, plus rapide)

npm install --save-dev vitest @testing-library/react @testing-library/user-event

Configuration de Vitest dans vitest.config.ts :

import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  test: {
    environment: 'jsdom',
    globals: true,
    setupFiles: './src/setupTests.ts',
  },
});

Testing Library (approche moderne basée sur l’accessibilité)

// Test moderne de composant avec Vitest et Testing Library
import { render, screen, userEvent } from '@testing-library/react';
import { test, expect, vi } from 'vitest';
import Counter from './Counter';

test('increments count when button is clicked', async () => {
  // Configurer
  const user = userEvent.setup();
  
  // Rendre
  render(<Counter initialCount={0} />);
  
  // Vérifier l'état initial
  expect(screen.getByText(/count: 0/i)).toBeInTheDocument();
  
  // Interagir
  await user.click(screen.getByRole('button', { name: /increment/i }));
  
  // Vérifier le résultat
  expect(screen.getByText(/count: 1/i)).toBeInTheDocument();
});

2.3.2 Tests de Hooks et Context

Tests des Hooks React (nouveauté importante) :

// Test de hook personnalisé
import { renderHook, act } from '@testing-library/react';
import { test, expect } from 'vitest';
import useCounter from './useCounter';

test('useCounter hook updates count', () => {
  const { result } = renderHook(() => useCounter(0));
  
  expect(result.current.count).toBe(0);
  
  act(() => {
    result.current.increment();
  });
  
  expect(result.current.count).toBe(1);
});

Tests de Context :

// Test de provider avec context
test('AuthProvider provides login functionality', async () => {
  const wrapper = ({ children }) => <AuthProvider>{children}</AuthProvider>;
  
  const { result } = renderHook(() => useAuth(), { wrapper });
  
  expect(result.current.isLoggedIn).toBe(false);
  
  await act(async () => {
    await result.current.login('user@example.com', 'password');
  });
  
  expect(result.current.isLoggedIn).toBe(true);
  expect(result.current.user.email).toBe('user@example.com');
});

2.3.3 Tests d’Interaction Avancés

Simulations d’interactions complexes :

test('form submission with validation', async () => {
  const onSubmit = vi.fn();
  const user = userEvent.setup();
  
  render(<RegistrationForm onSubmit={onSubmit} />);
  
  // Remplir le formulaire avec des données valides
  await user.type(screen.getByLabelText(/email/i), 'user@example.com');
  await user.type(screen.getByLabelText(/password/i), 'SecurePass123');
  await user.click(screen.getByLabelText(/terms/i)); // Checkbox
  
  // Soumettre
  await user.click(screen.getByRole('button', { name: /register/i }));
  
  // Vérifier que le handler a été appelé avec les bonnes données
  expect(onSubmit).toHaveBeenCalledWith({
    email: 'user@example.com',
    password: 'SecurePass123',
    termsAccepted: true
  });
});

2.3.4 Tests de Performance Frontend

tests de performance automatisés :

// Test de performance avec React Profiler API
import { Profiler } from 'react';
import { render } from '@testing-library/react';

test('DataGrid renders efficiently with 1000 rows', () => {
  let renderTime = 0;
  const onRender = (id, phase, actualDuration) => {
    renderTime = actualDuration;
  };
  
  render(
    <Profiler id="dataGrid" onRender={onRender}>
      <DataGrid rows={generateRows(1000)} />
    </Profiler>
  );
  
  // Vérifier que le temps de rendu est inférieur à 100ms
  expect(renderTime).toBeLessThan(100);
});

2.4 Tests d’Intégration

2.4.1 Tests d’API avec Laravel et Pest

// Test d'API moderne avec Pest
test('api returns paginated users', function () {
    // Créer 25 utilisateurs
    User::factory()->count(25)->create();
    
    // Authentifier un utilisateur admin
    $admin = User::factory()->admin()->create();
    $this->actingAs($admin);
    
    // Appeler l'API
    $response = $this->getJson('/api/users?page=1&per_page=10');
    
    // Assertions
    $response->assertStatus(200)
        ->assertJsonCount(10, 'data')
        ->assertJsonStructure([
            'data',
            'meta' => ['current_page', 'last_page', 'total']
        ]);
    
    expect($response->json('meta.total'))->toBe(26); // 25 + l'admin
    expect($response->json('meta.last_page'))->toBe(3);
});

2.4.2 Tests de Flux Utilisateur Complets

Test d’un processus complet (inscription, vérification d’email, connexion) :

test('complete user registration flow', function () {
    // 1. S'inscrire
    $response = $this->postJson('/api/register', [
        'name' => 'John Doe',
        'email' => 'john@example.com',
        'password' => 'Password123',
        'password_confirmation' => 'Password123'
    ]);
    
    $response->assertStatus(201);
    $userId = $response->json('id');
    
    // Vérifier que l'email est envoyé
    Mail::assertSent(VerifyEmail::class);
    
    // 2. Simuler la vérification d'email
    $user = User::find($userId);
    $verificationUrl = URL::temporarySignedRoute(
        'verification.verify',
        now()->addMinutes(60),
        ['id' => $userId, 'hash' => sha1($user->email)]
    );
    
    $this->get($verificationUrl)->assertStatus(302);
    
    // 3. Essayer de se connecter
    $this->postJson('/api/login', [
        'email' => 'john@example.com',
        'password' => 'Password123'
    ])->assertStatus(200)
      ->assertJsonStructure(['token', 'user']);
    
    // 4. Accéder à une ressource protégée
    $token = $this->postJson('/api/login', [
        'email' => 'john@example.com',
        'password' => 'Password123'
    ])->json('token');
    
    $this->withHeader('Authorization', "Bearer $token")
        ->getJson('/api/user/profile')
        ->assertStatus(200)
        ->assertJson(['email' => 'john@example.com']);
});

Test d’intégration complet avec MSW (Mock Service Worker) :

// Configuration de MSW pour simuler les réponses d'API
import { setupServer } from 'msw/node';
import { rest } from 'msw';
import { render, screen, waitFor } from '@testing-library/react';
import UserDashboard from './UserDashboard';

// Créer un serveur mock
const server = setupServer(
  rest.get('/api/user/profile', (req, res, ctx) => {
    return res(ctx.json({
      id: 1, 
      name: 'John Doe',
      email: 'john@example.com',
      subscription: 'premium'
    }));
  }),
  
  rest.get('/api/user/orders', (req, res, ctx) => {
    return res(ctx.json([
      { id: 101, amount: 99.99, status: 'completed' },
      { id: 102, amount: 149.99, status: 'processing' }
    ]));
  })
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('dashboard loads and displays user data from API', async () => {
  render(<UserDashboard />);
  
  // Vérifier le chargement initial
  expect(screen.getByText(/loading/i)).toBeInTheDocument();
  
  // Attendre que les données soient chargées
  await waitFor(() => {
    expect(screen.getByText('John Doe')).toBeInTheDocument();
  });
  
  // Vérifier que les données de profil sont affichées
  expect(screen.getByText('john@example.com')).toBeInTheDocument();
  expect(screen.getByText('Premium Member')).toBeInTheDocument();
  
  // Vérifier que les commandes sont affichées
  expect(screen.getByText('Order #101')).toBeInTheDocument();
  expect(screen.getByText('$99.99')).toBeInTheDocument();
  expect(screen.getByText('Order #102')).toBeInTheDocument();
  expect(screen.getByText('$149.99')).toBeInTheDocument();
});

2.5 Tests de Sécurité

2.5.1 Tests OWASP Top 10 2023

Les tests de sécurité doivent couvrir les vulnérabilités OWASP actualisées :

1. Broken Access Control

// Test d'accès non autorisé
test('regular user cannot access admin resources', function () {
    $regularUser = User::factory()->create();
    $this->actingAs($regularUser);
    
    $this->getJson('/api/admin/users')->assertStatus(403);
    $this->getJson('/api/admin/settings')->assertStatus(403);
    
    // Tenter d'accéder à une ressource d'un autre utilisateur
    $otherUser = User::factory()->create();
    $this->getJson("/api/users/{$otherUser->id}/private-data")->assertStatus(403);
});

1. Cryptographic Failures

// Vérifier le chiffrement correct des données sensibles
test('sensitive data is encrypted at rest', function () {
    $user = User::factory()->create([
        'credit_card' => '4242424242424242'
    ]);
    
    // Récupérer directement depuis la base pour vérifier le stockage
    $rawData = DB::table('users')->where('id', $user->id)->first();
    
    // Vérifier que la carte de crédit n'est pas stockée en clair
    expect($rawData->credit_card)->not->toBe('4242424242424242');
    
    // Vérifier que l'application peut toujours utiliser la donnée
    $this->actingAs($user);
    $response = $this->getJson('/api/user/payment-methods');
    $response->assertStatus(200)
        ->assertJson(['last_four' => '4242']);
});

1. Injection (SQL, NoSQL, Command)

// Test de protection contre les injections SQL
test('user search is protected against sql injection', function () {
    // Créer des utilisateurs test
    User::factory()->create(['name' => 'John Doe']);
    User::factory()->create(['name' => 'Jane Smith']);
    
    // Essayer une attaque par injection SQL
    $maliciousInput = "' OR 1=1; --";
    $this->actingAs(User::factory()->admin()->create());
    
    $response = $this->getJson("/api/users/search?q={$maliciousInput}");
    
    // Vérifier que l'attaque a échoué (pas de résultats ou erreur, mais pas tous les utilisateurs)
    $response->assertStatus(200);
    expect(count($response->json('data')))->toBeLessThan(2);
});

2.5.2 Tests de Conformité RGPD

Tests de conformité RGPD automatisés :

// Test de consentement et de suppression de données
test('user can delete their account with all data', function () {
    // Créer un utilisateur avec diverses données associées
    $user = User::factory()->create();
    Order::factory()->count(3)->create(['user_id' => $user->id]);
    Comment::factory()->count(5)->create(['user_id' => $user->id]);
    
    // Authentifier l'utilisateur
    $this->actingAs($user);
    
    // Demander la suppression du compte
    $response = $this->deleteJson('/api/user/account', [
        'password' => 'password',
        'confirmation' => 'DELETE MY ACCOUNT'
    ]);
    
    $response->assertStatus(200);
    
    // Vérifier que l'utilisateur et ses données sont supprimés
    $this->assertDatabaseMissing('users', ['id' => $user->id]);
    $this->assertDatabaseMissing('orders', ['user_id' => $user->id]);
    $this->assertDatabaseMissing('comments', ['user_id' => $user->id]);
});

// Test d'exportation de données personnelles
test('user can export their personal data', function () {
    $user = User::factory()->create();
    Order::factory()->count(3)->create(['user_id' => $user->id]);
    
    $this->actingAs($user);
    $response = $this->getJson('/api/user/data-export');
    
    $response->assertStatus(200)
        ->assertJsonStructure([
            'personal_information' => ['name', 'email', 'created_at'],
            'orders' => [['id', 'amount', 'created_at']],
            'preferences',
            'login_history'
        ]);
});

2.5.3 Tests de Sécurité Automatisés

Intégration de scanner SAST/DAST dans le workflow CI/CD :

# Dans .github/workflows/security.yml
name: Security Testing

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  security-sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: PHPStan Security Analysis
        run: |
          composer require --dev phpstan/phpstan-security
          vendor/bin/phpstan analyse --configuration=phpstan.neon
          
      - name: Node.js Security Scan
        run: |
          npm audit --production
          
  security-dast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up application
        run: |
          docker-compose up -d
          sleep 10  # Attendre que l'application démarre
          
      - name: ZAP Scan
        uses: zaproxy/action-baseline@v0.11.0
        with:
          target: 'http://localhost:8000'
          fail_action: false
          rules_file_name: '.zap/rules.tsv'

 

3. Automatisation et CI/CD

3.1 Pipeline d’Intégration Continue Moderne

Configuration GitHub Actions avec matrices et caching :

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  test-backend:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: [8.2, 8.3]
        
    services:
      mysql:
        image: mysql:8.0
        env:
          MYSQL_ROOT_PASSWORD: password
          MYSQL_DATABASE: testing
        ports:
          - 3306:3306
        options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3
        
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup PHP ${{ matrix.php-version }}
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          extensions: mbstring, dom, fileinfo, mysql
          coverage: xdebug
          
      - name: Get composer cache directory
        id: composer-cache
        run: echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
        
      - name: Cache composer dependencies
        uses: actions/cache@v3
        with:
          path: ${{ steps.composer-cache.outputs.dir }}
          key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
          restore-keys: ${{ runner.os }}-composer-
          
      - name: Install dependencies
        run: composer install --prefer-dist --no-progress
        
      - name: Run tests
        run: vendor/bin/pest --coverage
        env:
          DB_CONNECTION: mysql
          DB_HOST: 127.0.0.1
          DB_PORT: 3306
          DB_DATABASE: testing
          DB_USERNAME: root
          DB_PASSWORD: password
          
      - name: Upload code coverage
        uses: codecov/codecov-action@v3
        
  test-frontend:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20]
        
    steps:
      - uses: actions/checkout@v4
      
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Run linters
        run: npm run lint
        
      - name: Run tests
        run: npm test -- --coverage
        
      - name: Build application
        run: npm run build

3.2 Déploiement Moderne avec GitOps

Approche GitOps pour le déploiement continu :

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [ main ]
    
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup PHP 8.2
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.2
          extensions: mbstring, dom, fileinfo, mysql
          
      - name: Install Backend Dependencies
        run: composer install --no-dev --prefer-dist --no-progress
        
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'npm'
          
      - name: Install Frontend Dependencies
        run: npm ci
        
      - name: Build Frontend
        run: npm run build
        
      - name: Prepare Deployment Package
        run: |
          mkdir -p deploy
          # Exclure les fichiers non nécessaires
          cp -r app bootstrap config database public resources routes storage lang deploy/
          cp artisan composer.json composer.lock package.json webpack.mix.js deploy/
          cp -r build deploy/public/
          cp .env.example deploy/.env
          
      - name: Configure Environment
        run: |
          cat > deploy/.env << EOF
          APP_NAME=MyApp
          APP_ENV=staging
          APP_KEY=${{ secrets.APP_KEY }}
          APP_DEBUG=false
          APP_URL=https://staging.example.com
          
          DB_CONNECTION=mysql
          DB_HOST=${{ secrets.DB_HOST }}
          DB_PORT=3306
          DB_DATABASE=${{ secrets.DB_DATABASE }}
          DB_USERNAME=${{ secrets.DB_USERNAME }}
          DB_PASSWORD=${{ secrets.DB_PASSWORD }}
          
          MAIL_MAILER=smtp
          MAIL_HOST=${{ secrets.MAIL_HOST }}
          MAIL_PORT=587
          MAIL_USERNAME=${{ secrets.MAIL_USERNAME }}
          MAIL_PASSWORD=${{ secrets.MAIL_PASSWORD }}
          MAIL_ENCRYPTION=tls
          EOF
          
      - name: Deploy to Staging Server
        uses: easingthemes/ssh-deploy@main
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-rlgoDzvc --delete"
          SOURCE: "deploy/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_PATH }}
          
      - name: Post-Deployment Tasks
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.REMOTE_HOST }}
          username: ${{ secrets.REMOTE_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ${{ secrets.REMOTE_PATH }}
            php artisan migrate --force
            php artisan config:cache
            php artisan route:cache
            php artisan view:cache
            php artisan optimize
            chmod -R 775 storage bootstrap/cache
            
      - name: Run Smoke Tests
        run: |
          # Ping critical endpoints
          curl -s -o /dev/null -w "%{http_code}" https://staging.example.com/api/health | grep 200
          curl -s -o /dev/null -w "%{http_code}" https://staging.example.com/api/version | grep 200

3.3 Configuration Moderne des Environnements avec Docker

Configuration moderne avec conteneurisation :

# Dockerfile
FROM php:8.2-fpm-alpine

# Extensions PHP et dépendances
RUN apk add --no-cache \
    libpng-dev libjpeg-turbo-dev libwebp-dev \
    zip libzip-dev \
    oniguruma-dev \
    mariadb-client \
    && docker-php-ext-configure gd --with-jpeg --with-webp \
    && docker-php-ext-install pdo_mysql mbstring exif pcntl bcmath gd zip

# Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Configuration PHP
COPY docker/php/php.ini /usr/local/etc/php/conf.d/app.ini

WORKDIR /var/www/html

# Copie du code et permissions
COPY . .
RUN chown -R www-data:www-data /var/www/html/storage /var/www/html/bootstrap/cache

# Configuration docker-compose pour multi-environnements
```yaml
# docker-compose.yml
version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: ${APP_NAME}-app
    volumes:
      - ./:/var/www/html
      - ./docker/php/php.ini:/usr/local/etc/php/conf.d/app.ini
    depends_on:
      - db
    networks:
      - app-network
    environment:
      - APP_ENV=${APP_ENV}
      - DB_CONNECTION=mysql
      - DB_HOST=db
      - DB_PORT=3306
      - DB_DATABASE=${DB_DATABASE}
      - DB_USERNAME=${DB_USERNAME}
      - DB_PASSWORD=${DB_PASSWORD}

  nginx:
    image: nginx:alpine
    container_name: ${APP_NAME}-nginx
    ports:
      - "${APP_PORT}:80"
    volumes:
      - ./:/var/www/html
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - app
    networks:
      - app-network

  db:
    image: mysql:8.0
    container_name: ${APP_NAME}-db
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${DB_DATABASE}
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
      MYSQL_PASSWORD: ${DB_PASSWORD}
      MYSQL_USER: ${DB_USERNAME}
    volumes:
      - dbdata:/var/lib/mysql
    networks:
      - app-network

# Redis pour caching, queues et sessions
  redis:
    image: redis:alpine
    container_name: ${APP_NAME}-redis
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

volumes:
  dbdata:

3.4 Configuration Multi-Environnements Sécurisée

3.4.1 Gestion des Environnements avec dotenv

Stratégie moderne de gestion des environnements :

# Environnement local
.env.local       # Variables locales (jamais commité)
.env.example     # Template d'exemple (commité)

# Environnements de déploiement (générés dynamiquement)
.env.testing     # Pour les tests automatisés
.env.staging     # Pour l'environnement de pré-production
.env.production  # Pour la production

Utilisation des secrets GitHub Actions pour stocker les variables sensibles :

# Configuration via GitHub Secrets
- name: Configure Environment
  run: |
    cat > .env << EOF
    APP_NAME=${APP_NAME}
    APP_ENV=${APP_ENV}
    APP_KEY=${APP_KEY}
    APP_DEBUG=${APP_DEBUG}
    APP_URL=${APP_URL}
    
    DB_CONNECTION=mysql
    DB_HOST=${DB_HOST}
    DB_PORT=3306
    DB_DATABASE=${DB_DATABASE}
    DB_USERNAME=${DB_USERNAME}
    DB_PASSWORD=${DB_PASSWORD}
    
    MAIL_MAILER=smtp
    MAIL_HOST=${MAIL_HOST}
    MAIL_PORT=587
    MAIL_USERNAME=${MAIL_USERNAME}
    MAIL_PASSWORD=${MAIL_PASSWORD}
    MAIL_ENCRYPTION=tls
    EOF
  env:
    APP_NAME: ${{ secrets.APP_NAME }}
    APP_ENV: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}
    APP_KEY: ${{ secrets.APP_KEY }}
    APP_DEBUG: ${{ github.ref == 'refs/heads/main' && 'false' || 'true' }}
    APP_URL: ${{ github.ref == 'refs/heads/main' && secrets.PROD_APP_URL || secrets.STAGING_APP_URL }}
    DB_HOST: ${{ secrets.DB_HOST }}
    DB_DATABASE: ${{ secrets.DB_DATABASE }}
    DB_USERNAME: ${{ secrets.DB_USERNAME }}
    DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
    MAIL_HOST: ${{ secrets.MAIL_HOST }}
    MAIL_USERNAME: ${{ secrets.MAIL_USERNAME }}
    MAIL_PASSWORD: ${{ secrets.MAIL_PASSWORD }}

3.4.2 Bannières d’Environnement Modernes

Configuration React avec indicateur visuel d’environnement :

// src/components/EnvironmentBanner.jsx
import { useEffect, useState } from 'react';

const EnvironmentBanner = () => {
  const [environment, setEnvironment] = useState(null);
  
  useEffect(() => {
    // Récupérer la configuration depuis une API backend
    fetch('/api/config/environment')
      .then(res => res.json())
      .then(data => setEnvironment(data.environment));
  }, []);
  
  if (!environment || environment === 'production') return null;
  
  const colors = {
    development: 'bg-blue-600',
    testing: 'bg-green-600',
    staging: 'bg-orange-600'
  };
  
  return (
    <div className={`${colors[environment]} text-white text-center py-1 px-2 text-sm md:text-base w-full`}>
      {environment.toUpperCase()} ENVIRONMENT - NOT FOR PRODUCTION USE
    </div>
  );
};

export default EnvironmentBanner;

3.5 Monitoring et Observabilité

Nouveauté – Intégration du monitoring dans le pipeline :

# .github/workflows/monitoring.yml
name: Monitoring & Alerting

on:
  schedule:
    - cron: '*/15 * * * *'  # Toutes les 15 minutes
  workflow_dispatch:  # Déclenchement manuel

jobs:
  uptime-check:
    runs-on: ubuntu-latest
    steps:
      - name: Check API Health
        id: health-check
        run: |
          STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health)
          echo "status=$STATUS" >> $GITHUB_OUTPUT
          if [ "$STATUS" != "200" ]; then
            echo "::error::API Health check failed with status $STATUS"
            exit 1
          fi
          
      - name: Notify on Failure
        if: failure()
        uses: slackapi/slack-github-action@v1.25.0
        with:
          channel-id: 'monitoring-alerts'
          slack-message: 'API Health Check FAILED! Environment: ${{ github.ref == 'refs/heads/main' && 'PRODUCTION' || 'STAGING' }}'
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

Configuration du monitoring applicatif :

 

// config/logging.php
return [
    'channels' => [
        'stack' => [
            'driver' => 'stack',
            'channels' => ['single', 'sentry'],
        ],
        
        'sentry' => [
            'driver' => 'sentry',
            'level'  => env('LOG_LEVEL', 'error'),
        ],
        
        // Autres canaux de log...
    ],
];

 

// app/Exceptions/Handler.php
public function register()
{
    $this->reportable(function (Throwable $e) {
        if (app()->bound('sentry')) {
            app('sentry')->captureException($e);
        }
        
        // Enregistrer des métriques personnalisées
        $this->recordErrorMetrics($e);
    });
}

protected function recordErrorMetrics(Throwable $e)
{
    // Exemple avec Prometheus/StatsD
    $tags = [
        'exception' => get_class($e),
        'code' => $e->getCode(),
        'file' => basename($e->getFile()),
    ];
    
    app('metrics')->increment('application_errors_total', 1, $tags);
}

 

3.6 Tests de Charge et Performance

Tests de performance avancés :

// tests/performance/api-load-test.js
import { check, sleep } from 'k6';
import http from 'k6/http';
import { Counter, Rate, Trend } from 'k6/metrics';

// Métriques personnalisées
const errors = new Counter('errors');
const tokenRefreshes = new Counter('token_refreshes');
const searchLatency = new Trend('search_latency');
const successRate = new Rate('success_rate');

export const options = {
  stages: [
    { duration: '1m', target: 50 },   // Montée progressive à 50 VU
    { duration: '3m', target: 50 },   // Stabilisation à 50 VU
    { duration: '1m', target: 100 },  // Montée à 100 VU
    { duration: '5m', target: 100 },  // Test de charge à 100 VU
    { duration: '1m', target: 0 },    // Retour à 0 VU
  ],
  thresholds: {
    // Seuils de performance
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    'http_req_duration{name:search}': ['p(95)<300'],
    'http_req_duration{name:login}': ['p(95)<400'],
    'success_rate': ['rate>0.95'],
  },
};

// Simulation d'utilisateur
export default function() {
  // 1. Connexion
  let loginRes = http.post('https://api.example.com/login', {
    email: `user${__VU}@example.com`,
    password: 'Password123',
  }, {
    tags: { name: 'login' },
  });
  
  check(loginRes, {
    'login successful': (r) => r.status === 200 && r.json('token') !== undefined,
  }) || errors.add(1);
  
  const token = loginRes.json('token');
  
  // 2. Recherche de produits (avec latence mesurée)
  const searchStart = new Date();
  const searchRes = http.get('https://api.example.com/products/search?q=smartphone', {
    headers: { Authorization: `Bearer ${token}` },
    tags: { name: 'search' },
  });
  searchLatency.add(new Date() - searchStart);
  
  check(searchRes, {
    'search successful': (r) => r.status === 200,
    'search has results': (r) => r.json('products').length > 0,
  }) || errors.add(1);
  
  successRate.add(searchRes.status === 200);
  
  // 3. Consulter un produit
  const productId = searchRes.json('products.0.id');
  const productRes = http.get(`https://api.example.com/products/${productId}`, {
    headers: { Authorization: `Bearer ${token}` },
    tags: { name: 'product_details' },
  });
  
  check(productRes, {
    'product details successful': (r) => r.status === 200,
  }) || errors.add(1);
  
  // 4. Ajouter au panier
  const cartRes = http.post('https://api.example.com/cart/items', {
    product_id: productId,
    quantity: 1,
  }, {
    headers: { Authorization: `Bearer ${token}` },
    tags: { name: 'add_to_cart' },
  });
  
  check(cartRes, {
    'add to cart successful': (r) => r.status === 201 || r.status === 200,
  }) || errors.add(1);
  
  // Pause entre les actions utilisateur
  sleep(Math.random() * 3 + 2); // 2-5 secondes
}

Intégration dans le pipeline :

# .github/workflows/performance.yml
name: Performance Tests

on:
  schedule:
    - cron: '0 3 * * 1'  # Tous les lundis à 3h du matin
  workflow_dispatch:

jobs:
  k6-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run k6 load test
        uses: grafana/k6-action@v0.3.0
        with:
          filename: tests/performance/api-load-test.js
          flags: --out json=results.json
          
      - name: Upload results
        uses: actions/upload-artifact@v3
        with:
          name: k6-results
          path: results.json
          
      - name: Analyze results
        run: |
          cat results.json | jq '.metrics.http_req_duration.values.p95'
          cat results.json | jq '.metrics.http_req_duration.values.p99'
          
          P95=$(cat results.json | jq '.metrics.http_req_duration.values.p95')
          if (( $(echo "$P95 > 500" | bc -l) )); then
            echo "::warning::Performance degraded! p95 latency is ${P95}ms"
          fi

 

4. Pratiques DevSecOps Avancées

4.1 Gestion des Secrets

Utilisation de HashiCorp Vault pour la gestion des secrets :

// config/secrets.php
return [
    'provider' => env('SECRETS_PROVIDER', 'env'),
    
    'providers' => [
        'env' => [
            'driver' => 'env',
        ],
        
        'vault' => [
            'driver' => 'vault',
            'url' => env('VAULT_ADDR'),
            'token' => env('VAULT_TOKEN'),
            'mount' => env('VAULT_MOUNT', 'secret'),
            'path' => env('VAULT_PATH', 'application'),
        ],
    ],
];

 

// app/Services/SecretsManager.php
class SecretsManager
{
    protected $provider;
    
    public function __construct()
    {
        $this->provider = config('secrets.provider');
    }
    
    public function get(string $key, $default = null)
    {
        switch ($this->provider) {
            case 'vault':
                return $this->getFromVault($key, $default);
                
            case 'env':
            default:
                return env($key, $default);
        }
    }
    
    protected function getFromVault(string $key, $default)
    {
        try {
            $client = new \Vault\Client(config('secrets.providers.vault.url'));
            $client->authenticate(config('secrets.providers.vault.token'));
            
            $path = config('secrets.providers.vault.path');
            $mount = config('secrets.providers.vault.mount');
            
            $secrets = $client->secrets()->kv()->v2($mount)->get($path);
            return $secrets['data'][$key] ?? $default;
        } catch (\Exception $e) {
            report($e);
            return $default;
        }
    }
}

 

4.2 Sécurité des Conteneurs

Scan de sécurité des conteneurs dans le pipeline :

# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [ main, develop ]
    paths:
      - 'Dockerfile'
      - 'docker-compose.yml'
      - '.github/workflows/container-security.yml'

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t app-image:${{ github.sha }} .
        
      - name: Trivy vulnerability scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'app-image:${{ github.sha }}'
          format: 'table'
          exit-code: '1'
          ignore-unfixed: true
          severity: 'CRITICAL,HIGH'
          
      # Notification en cas d'échec
      - name: Notify on vulnerability
        if: failure()
        uses: slackapi/slack-github-action@v1.25.0
        with:
          channel-id: 'security-alerts'
          slack-message: 'Container security vulnerabilities detected! See: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}'
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

 

4.3 Infrastructure as Code (IaC)

Exemple de configuration Terraform pour l’infrastructure :

# main.tf
provider "aws" {
  region = var.aws_region
}

# VPC et sous-réseaux
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  
  name = "${var.project_name}-vpc"
  cidr = "10.0.0.0/16"
  
  azs             = ["${var.aws_region}a", "${var.aws_region}b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]
  
  enable_nat_gateway = true
  single_nat_gateway = true
  
  tags = var.tags
}

# Base de données RDS
resource "aws_db_instance" "database" {
  identifier           = "${var.project_name}-db"
  allocated_storage    = 20
  storage_type         = "gp2"
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"
  name                 = var.db_name
  username             = var.db_username
  password             = var.db_password
  parameter_group_name = "default.mysql8.0"
  skip_final_snapshot  = true
  
  vpc_security_group_ids = [aws_security_group.db_sg.id]
  db_subnet_group_name   = aws_db_subnet_group.db_subnet.name
  
  tags = var.tags
}

# Groupe de sécurité pour la base de données
resource "aws_security_group" "db_sg" {
  name        = "${var.project_name}-db-sg"
  description = "Allow access to RDS from ECS"
  vpc_id      = module.vpc.vpc_id
  
  ingress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    security_groups = [aws_security_group.ecs_sg.id]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  tags = var.tags
}

# Configuration ECS pour l'application
resource "aws_ecs_cluster" "app_cluster" {
  name = "${var.project_name}-cluster"
  tags = var.tags
}

resource "aws_ecs_task_definition" "app_task" {
  family                   = "${var.project_name}-task"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 256
  memory                   = 512
  execution_role_arn       = aws_iam_role.ecs_execution_role.arn
  
  container_definitions = jsonencode([
    {
      name      = "${var.project_name}-container"
      image     = var.ecr_repository_url
      essential = true
      portMappings = [
        {
          containerPort = 80
          hostPort      = 80
        }
      ]
      environment = [
        {
          name  = "APP_ENV"
          value = var.environment
        },
        {
          name  = "DB_HOST"
          value = aws_db_instance.database.address
        },
        {
          name  = "DB_DATABASE"
          value = var.db_name
        },
        {
          name  = "DB_USERNAME"
          value = var.db_username
        }
      ]
      secrets = [
        {
          name      = "APP_KEY"
          valueFrom = "${aws_secretsmanager_secret.app_secrets.arn}:APP_KEY::"
        },
        {
          name      = "DB_PASSWORD"
          valueFrom = "${aws_secretsmanager_secret.app_secrets.arn}:DB_PASSWORD::"
        }
      ]
      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = aws_cloudwatch_log_group.app_logs.name
          "awslogs-region"        = var.aws_region
          "awslogs-stream-prefix" = "ecs"
        }
      }
    }
  ])
  
  tags = var.tags
}

# Gestion des secrets avec AWS Secrets Manager
resource "aws_secretsmanager_secret" "app_secrets" {
  name = "${var.project_name}-${var.environment}-secrets"
  tags = var.tags
}

resource "aws_secretsmanager_secret_version" "app_secrets_version" {
  secret_id = aws_secretsmanager_secret.app_secrets.id
  secret_string = jsonencode({
    APP_KEY     = var.app_key
    DB_PASSWORD = var.db_password
  })
}

 

Cette stratégie modernisée de tests, sécurité et CI/CD  intègre :

1. Tests avancés :
   • Adoption de Pest pour le backend (syntaxe plus expressive)
   • Vitest et Testing Library pour le frontend (performance et accessibilité)
   • Tests de sécurité selon OWASP Top 10 2023
   • Tests de conformité RGPD automatisés
   • Tests de performance avec K6
2. DevSecOps intégré :
   • Analyse statique et dynamique de sécurité
   • Scan de conteneurs
   • Gestion sécurisée des secrets
   • Conformité réglementaire
3. CI/CD optimisé :
   • GitHub Actions avec matrices de test
   • Approche GitOps
   • Infrastructure as Code avec Terraform
   • Monitoring et observabilité
4. Conteneurisation :
   • Docker pour tous les environnements
   • Configuration multi-environnements cohérente
   • Séparation claire des préoccupations

Cette stratégie s’aligne sur les meilleures pratiques , assurant un développement rapide, sécurisé et de haute qualité. L’approche shift-left adoptée permet de détecter les problèmes au plus tôt, réduisant les coûts et accélérant les cycles de livraison.

 

Recommandations pour la mise en œuvre

Priorisation des changements

Pour implémenter cette stratégie actualisée, je recommande de procéder par phases :

1. Phase 1 : Fondations des tests (1-2 mois)
   • Migrer vers Pest pour les tests backend (plus moderne que PHPUnit)
   • Mettre à jour les tests frontend avec Vitest et React Testing Library
   • Configurer les tests de sécurité de base (CSRF, XSS, autorisations)
2. Phase 2 : CI/CD moderne (1 mois)
   • Configurer GitHub Actions avec matrices de test
   • Mettre en place les environnements avec Docker
   • Automatiser le déploiement vers staging/production
3. Phase 3 : Sécurité avancée (1-2 mois)
   • Implémenter les tests OWASP Top 10 2023
   • Ajouter les scans de sécurité dans le pipeline
   • Configurer la gestion sécurisée des secrets
4. Phase 4 : Observabilité et optimisation (1 mois)
   • Ajouter le monitoring et les alertes
   • Mettre en place les tests de performance
   • Optimiser le pipeline CI/CD

Points d’attention particuliers

1. Versions technologiques :
   • Laravel 11 est effectivement disponible depuis mars 2024
   • React 18 est la version actuelle (pas React 19 comme indiqué dans le document original)
2. Outils modernes :
   • Pest est désormais le standard pour les tests Laravel (plutôt que PHPUnit)
   • Vitest remplace progressivement Jest pour les tests React (plus rapide)
   • Docker est essentiel pour assurer la cohérence entre environnements
3. Sécurité renforcée :
   • Les tests de sécurité doivent couvrir l’OWASP Top 10 2023
   • La conformité RGPD doit être testée automatiquement
   • La gestion des secrets doit être sécurisée (HashiCorp Vault ou AWS Secrets Manager)
4. Performance et surveillance :
   • K6 est l’outil recommandé pour les tests de charge
   • Les seuils de performance doivent être définis et surveillés
   • La surveillance continue doit être mise en place