Qu'est-ce que le CI/CD ? Intégration et livraison continues expliquées simplement

Le CI/CD est une façon de livrer un logiciel où chaque modification de code est automatiquement compilée, testée et — si elle réussit — préparée pour la publication ou publiée. CI (intégration continue) signifie que les modifications sont fusionnées souvent et vérifiées par des tests automatisés à chaque fois. CD (livraison ou déploiement continu) signifie que les modifications qui réussissent sont empaquetées et acheminées vers vos utilisateurs avec peu ou pas d'intervention manuelle.

L'objectif est simple : détecter les erreurs quelques minutes après leur création, et non des semaines plus tard, quand un client les découvre.

Pourquoi le CI/CD compte quand on construit avec l'IA

Les créateurs d'applis par IA modifient le code très vite. Un seul prompt peut toucher dix fichiers. Cette rapidité est formidable, jusqu'au jour où une modification de la page de paiement casse discrètement la page de connexion, et que personne ne s'en rend compte avant qu'un utilisateur vous écrive.

Le CI/CD est le filet de sécurité précisément pour cela. Au lieu de supposer que chaque modification est correcte, un pipeline exécute les mêmes vérifications à chaque fois :

• L'appli se compile-t-elle encore sans erreur ?
• Les tests automatisés passent-ils toujours ?
• Le code respecte-t-il les règles du projet (types, formatage, contrôles de sécurité) ?

Si une vérification échoue, la modification est arrêtée avant d'atteindre les utilisateurs. Plus votre code change vite, plus une vérification qui ne se fatigue jamais et ne saute jamais d'étape prend de la valeur.

Une analogie du quotidien

Pensez à une boulangerie qui livre du pain chaque matin à des épiceries.

• Sans CI/CD, chaque boulanger travaille seul sur ses ajustements de recette pendant une semaine, puis tout le monde combine ses changements le vendredi soir et espère que le pain lèvera encore. Quand ce n'est pas le cas, personne ne sait quelle modification en est la cause.
• Avec le CI, chaque petit changement de recette est immédiatement cuit en fournée test et contrôlé — goût, poids, forme. Un mauvais changement est repéré le jour même, et on sait exactement lequel c'était.
• Avec le CD, les pains qui passent le contrôle partent directement dans le camion de livraison, emballés et étiquetés toujours de la même façon, au lieu que quelqu'un emballe les caisses à la main à 5 heures du matin.

Le contrôle ne rend pas les boulangers meilleurs. Il rend leurs erreurs peu coûteuses.

Comment fonctionne un pipeline CI/CD

Un pipeline est une liste d'étapes qu'un service CI/CD exécute automatiquement quand quelque chose se produit — en général quand quelqu'un pousse du code vers un dépôt comme GitHub. Un pipeline typique ressemble à ceci :

Chaque étape s'exécute sur une machine propre, et non sur l'ordinateur de quelqu'un, donc « ça marche sur mon ordinateur » ne sert plus d'excuse. Si une étape échoue, le pipeline s'arrête et prévient la personne qui a fait la modification.

Les étapes sont définies dans un fichier de configuration qui vit avec le code. Dans GitHub Actions, par exemple, c'est un fichier YAML dans le dossier .github/workflows du dépôt.

Livraison continue ou déploiement continu

Le « CD » est ambigu, et les gens l'utilisent dans les deux sens :

Le déploiement continu ne fonctionne bien que si les tests sont bons. Si vos tests ne couvrent pas le paiement, le déploiement continu livrera allègrement un paiement cassé.

Un exemple concret : une appli de réservation avec un pipeline

Imaginons que vous avez une appli de réservation pour un salon de coiffure, et que son code est dans un dépôt GitHub. Vous demandez à un créateur d'applis par IA d'« ajouter une remise de 10 % pour les premiers clients ».

1. La modification est poussée sur une nouvelle branche et une pull request est ouverte.
2. Le pipeline démarre. Il installe les paquets et compile l'appli — cela réussit.
3. Il lance les tests. Un test, « un client qui revient paie le plein tarif », échoue : la remise s'applique à tout le monde.
4. La pull request affiche une croix rouge. La modification ne peut pas être fusionnée.
5. Vous demandez à l'IA de corriger. Elle pousse une correction ; le pipeline se relance et tout passe.
6. La modification est fusionnée. Le pipeline la déploie dans un environnement de préproduction, où vous testez une réservation d'essai.
7. Vous validez, et elle est déployée en production.

Sans le pipeline, l'étape 3 se serait produite dans le portefeuille de vos clients.

Termes clés

Idées reçues

• « Le CI/CD signifie que mon appli est testée. » Un pipeline n'exécute que les tests que vous avez. S'il n'y a pas de tests, le CI prouve seulement que l'appli se compile — rien de plus. Demandez à votre IA d'écrire des tests pour les parcours les plus importants.
• « Le CI/CD ne sert qu'aux grandes entreprises. » Les outils hébergés comme GitHub Actions se configurent avec un court fichier de configuration, et les petites équipes les utilisent tout le temps. Ce sont les tests, et non l'outillage, qui demandent de l'effort.
• « Le déploiement automatique signifie que personne ne vérifie rien. » De bons pipelines ajoutent des contrôles, ils n'en retirent pas. Beaucoup d'équipes gardent une étape de validation humaine avant la production.
• « Si le pipeline est vert, l'appli fonctionne. » Cela signifie que les contrôles automatisés ont réussi. Vous devez tout de même essayer la modification vous-même, idéalement dans un aperçu ou en préproduction.
• « Le CI/CD remplace les sauvegardes. » Non. Une migration de base de données défectueuse qui passe les tests peut quand même endommager de vraies données. Gardez des sauvegardes et un moyen de revenir en arrière.

Quoi demander à votre créateur d'applis par IA

• « Écris des tests automatisés pour l'inscription, la connexion et le paiement, et montre-moi comment les lancer. »
• « Mets en place un workflow GitHub Actions qui installe les dépendances, compile l'appli et lance les tests à chaque pull request. »
• « Ajoute une vérification de types et un linter au pipeline, et fais-le échouer en cas d'erreur. »
• « Explique en français simple ce que fait chaque étape du pipeline. »
• « Que se passe-t-il si un déploiement échoue à mi-parcours ? Comment revenir en arrière ? »
• « Vérifie qu'aucun secret n'est codé en dur dans le dépôt ni affiché dans les journaux du pipeline. »

Si votre appli utilise des clés d'API, le pipeline en a besoin aussi — stockées comme secrets chiffrés dans l'outil CI, jamais dans le fichier de configuration. Voir variables d'environnement et secrets.

Le CI/CD et Mythex

Mythex ne fait pas tourner de pipeline CI pour vous, mais il couvre plusieurs des mêmes besoins à sa façon :

• Points de contrôle. Après chaque tour de l'agent réussi, Mythex enregistre un point de contrôle git, et Revenir à ce point ramène le projet en arrière si une modification a mal tourné. Voir Chat.
• Tests de l'appli. Tapez /test et l'agent parcourt votre aperçu en direct comme un utilisateur, puis signale les parcours cassés — utile avant chaque publication. Voir Tests de l'appli.
• La publication est une étape délibérée. Les modifications apparaissent d'abord dans l'aperçu privé ; votre appli publique ne se met à jour que lorsque vous publiez à nouveau — plus proche de la livraison continue que du déploiement continu.
• Synchronisation GitHub (Pro). Synchronisez le projet avec un dépôt GitHub et vous pouvez ajouter vos propres workflows GitHub Actions pour lancer des tests à chaque push. Voir GitHub et export.

Pour une liste de contrôle de ce qu'il faut tester à la main avant la mise en ligne, voir comment tester votre appli avant le lancement, et pour travailler avec le contrôle de version, comment utiliser Git avec une appli créée par IA.

Questions