CI/CD

Le CI/CD regroupe deux pratiques complémentaires qui automatisent le cycle de vie du code, du moment où un développeur propose une modification jusqu’au moment où elle est disponible pour les utilisateurs.

La CI (Continuous Integration, ou intégration continue) vérifie automatiquement chaque modification de code : est-ce que ça compile ? Est-ce que les tests passent ? Est-ce que le style du code est conforme aux conventions ? Si quelque chose échoue, l’équipe est alertée immédiatement, avant que le problème ne se propage.

Le CD (Continuous Deployment, ou déploiement continu) prend le relais : une fois que les vérifications automatiques sont passées, le code est déployé automatiquement — d’abord sur un environnement de test (staging), puis en production. Sans intervention manuelle, sans oubli, sans stress.

Avant et après le CI/CD

Sans CI/CD, le processus ressemble souvent à ceci : un développeur écrit du code, le teste manuellement sur sa machine, le livre à un collègue qui le déploie manuellement sur le serveur de production. C’est lent, sujet aux erreurs, et chaque déploiement est un moment de tension — personne n’est jamais sûr à 100 % que tout va bien se passer.

Avec CI/CD, le processus est transformé : le développeur propose sa modification via Git, un pipeline automatisé lance les vérifications en quelques minutes, et si tout est validé, le code est déployé automatiquement. Les déploiements deviennent un non-événement — plusieurs fois par jour si nécessaire, sans panique ni cérémonie.

Ce que vérifie un pipeline CI

Un pipeline CI bien configuré enchaîne plusieurs étapes de vérification, chacune avec son rôle.

Le linting vérifie le style et la syntaxe du code. C’est la première ligne de défense — rapide (quelques secondes) et efficace pour attraper les erreurs triviales : une variable mal nommée, une importation manquante, un format incohérent.

Les tests unitaires vérifient que chaque fonction individuelle fonctionne correctement, isolément du reste. Ils couvrent la logique métier : est-ce que le calcul de la LTV renvoie le bon résultat ? Est-ce que la validation d’un formulaire rejette bien les données invalides ?

Les tests d’intégration vérifient que les modules fonctionnent bien ensemble : est-ce que l’API répond correctement quand on lui envoie une requête ? Est-ce que la création d’un utilisateur s’enregistre bien en base de données ?

La vérification de types (avec TypeScript) s’assure que le code est cohérent du point de vue des types de données. C’est une couche de sécurité supplémentaire qui détecte des erreurs à la compilation plutôt qu’en production.

La compilation (build) vérifie que l’application peut être construite et empaquetée sans erreur — une étape indispensable avant tout déploiement.

Le déploiement continu

Une fois les vérifications passées, le code est prêt à être déployé. Le pipeline CD construit une image de l’application (souvent via Docker), la pousse vers un registre, puis met à jour l’environnement cible.

La bonne pratique est de déployer d’abord sur un environnement de staging — une copie de la production avec des données de test — pour valider le comportement dans des conditions réalistes. Si tout fonctionne, le même processus se répète pour la production.

Pour les applications qui ne peuvent pas se permettre d’interruption, des techniques comme le déploiement bleu-vert permettent de préparer la nouvelle version en parallèle de l’ancienne et de basculer le trafic instantanément. Si un problème est détecté, on revient à la version précédente en quelques secondes.

Pourquoi c’est un investissement rentable

Le bénéfice le plus immédiat est la détection précoce des bugs. Un problème repéré cinq minutes après le commit coûte infiniment moins cher à corriger qu’un problème découvert en production par un utilisateur trois jours plus tard. C’est aussi l’un des meilleurs remparts contre l’accumulation de dette technique.

Le deuxième bénéfice est la fréquence de déploiement. Livrer une petite modification est beaucoup moins risqué que livrer trois semaines de travail d’un coup. Plus les déploiements sont fréquents et petits, plus les problèmes sont faciles à identifier et à corriger.

Le troisième est le confort de l’équipe. Quand les déploiements sont automatisés et fiables, l’équipe ne redoute plus les mises en production. C’est un changement culturel majeur : on passe de “on déploie le vendredi soir en croisant les doigts” à “on déploie plusieurs fois par jour sans y penser”.

Enfin, le CI/CD produit un historique d’audit complet : qui a déployé quoi, quand, avec quels résultats de tests. C’est indispensable pour la conformité et utile pour le débogage.

Les erreurs courantes

La première est les tests instables (flaky tests). Un test qui passe 90 % du temps et échoue 10 % du temps mine la confiance de toute l’équipe dans le pipeline. Les tests doivent être déterministes — même entrée, même résultat, à chaque fois.

La deuxième est un pipeline trop lent. Si le pipeline prend 30 minutes, les développeurs cessent d’attendre les résultats et livrent du code sans vérification. L’objectif est de rester sous 10 à 15 minutes.

La troisième est l’absence d’environnement de staging. Déployer directement en production sans passer par un environnement de test, c’est faire prendre un risque aux utilisateurs à chaque modification.

La quatrième est l’absence d’alertes. Un pipeline qui échoue silencieusement ne sert à rien. Chaque échec doit être notifié immédiatement (Slack, email) pour que l’équipe réagisse vite.

Les outils les plus courants

GitHub Actions est devenu la référence pour les projets hébergés sur GitHub : intégré, bien documenté et gratuit pour un usage raisonnable. GitLab CI offre des fonctionnalités similaires avec la possibilité d’être hébergé en interne. CircleCI est apprécié pour son expérience développeur soignée. Jenkins, le vétéran, reste utilisé dans les grandes entreprises mais demande davantage de configuration et de maintenance.

Comment Polara Studio met en place le CI/CD

Chez Polara Studio, le CI/CD est configuré dès le premier jour de chaque projet. Nous utilisons GitHub Actions pour automatiser l’ensemble du pipeline : à chaque proposition de modification, le code est vérifié (linting, vérification de types, tests unitaires, tests d’intégration, compilation). À chaque fusion sur la branche principale, l’application est automatiquement déployée sur l’environnement de staging.

Le déploiement en production est déclenché par un tag de version — une release — ce qui garantit un contrôle explicite du moment de la mise en ligne. Sentry capture les erreurs en temps réel, et des alertes automatiques préviennent l’équipe en cas d’anomalie post-déploiement. L’objectif : que le chemin entre “le code est prêt” et “les utilisateurs en profitent” soit le plus court et le plus sûr possible.