Qu'est-ce que le CI/CD? L'intégration et le déploiement continus expliqués simplement

Le CI/CD est une façon de livrer des logiciels où chaque modification du code est automatiquement compilée, testée et — si elle réussit — préparée pour la mise en production ou mise en ligne. 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 de travail manuel.

Le principe est simple : détecter les erreurs quelques minutes après leur création, et non des semaines plus tard, quand un client les trouve.

Pourquoi le CI/CD compte quand vous construisez avec l'IA

Les créateurs d'apps IA modifient le code rapidement. Une seule consigne peut toucher dix fichiers. Cette rapidité est excellente, jusqu'au moment où une modification de la page de paiement brise discrètement la page de connexion, et que personne ne le remarque avant qu'un utilisateur vous écrive.

Le CI/CD est le filet de sécurité qui répond exactement à ce problème. Au lieu de supposer que chaque modification est correcte, un pipeline exécute les mêmes vérifications à chaque fois :

• L'app 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 bloquée avant d'atteindre les utilisateurs. Plus vos modifications de code sont rapides, plus une vérification qui ne se fatigue jamais et ne saute aucune étape prend de la valeur.

Une analogie du quotidien

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

• 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 dans une miche d'essai et vérifié — goût, poids, forme. Une mauvaise modification est détectée le jour même, et vous savez exactement laquelle.
• Avec le CD, les pains qui passent l'inspection montent directement dans le camion de livraison, emballés et étiquetés toujours de la même façon, au lieu que quelqu'un emballe des boîtes à la main à 5 h du matin.

L'inspection ne rend pas les boulangers meilleurs. Elle 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 lorsque quelque chose se produit — généralement lorsqu'une personne 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 portable de quelqu'un, donc « ça marche sur mon ordinateur » n'est plus une excuse. Si une étape échoue, le pipeline s'arrête et avertit 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 contre 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 brisé.

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

Disons que vous avez une app 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'apps IA d'« ajouter un rabais de 10 % pour les nouveaux clients ».

1. La modification est poussée dans une nouvelle branche et une demande de fusion (pull request) est ouverte.
2. Le pipeline démarre. Il installe les paquets et compile l'app — cela réussit.
3. Il exécute les tests. Un test, « un client de retour paie le plein tarif », échoue : le rabais est appliqué à tout le monde.
4. La demande de fusion affiche une croix rouge. La modification ne peut pas être fusionnée.
5. Vous demandez à l'IA de corriger le problème. Elle pousse une correction; le pipeline s'exécute à nouveau et tout passe.
6. La modification est fusionnée. Le pipeline la déploie dans un environnement de préproduction, où vous essayez une réservation de test.
7. Vous approuvez, 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 fausses courantes

• « Le CI/CD signifie que mon app est testée. » Un pipeline exécute seulement les tests que vous avez. S'il n'y en a pas, le CI prouve seulement que l'app se compile — rien de plus. Demandez à votre IA d'écrire des tests pour les parcours les plus importants.
• « Le CI/CD est réservé aux grandes entreprises. » Les outils hébergés comme GitHub Actions demandent un court fichier de configuration pour être mis en place, 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. » Les bons pipelines ajoutent des vérifications, ils n'en retirent pas. Beaucoup d'équipes gardent une étape d'approbation humaine avant la production.
• « Si le pipeline est vert, l'app fonctionne. » Cela signifie que les vérifications automatisées ont réussi. Vous devriez 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 malencontreuse 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'apps IA

• « Écris des tests automatisés pour l'inscription, la connexion et le paiement, et montre-moi comment les exécuter. »
• « Configure un workflow GitHub Actions qui installe les dépendances, compile l'app et exécute les tests à chaque demande de fusion. »
• « 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-chemin? Comment revenir en arrière? »
• « Vérifie qu'aucun secret n'est écrit en dur dans le dépôt ou affiché dans les journaux du pipeline. »

Si votre app 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 n'exécute pas de pipeline CI pour vous, mais il couvre plusieurs des mêmes besoins à sa façon :

• Points de contrôle. Après chaque tour réussi de l'agent, 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'app. Tapez /test et l'agent parcourt votre aperçu en direct comme un utilisateur et signale les parcours brisés — utile avant chaque publication. Voir Tests de l'app.
• La publication est une étape délibérée. Les modifications apparaissent d'abord dans l'aperçu privé; votre app 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 exécuter des tests à chaque envoi. Voir GitHub et export.

Pour une liste de contrôle des tests à faire à la main avant la mise en ligne, voir comment tester votre app avant le lancement, et pour travailler avec le contrôle de version, comment utiliser Git avec une app construite par IA.

Questions