Pourquoi les outils CI/CD natifs AWS et tiers ne se valent pas sur le même contexte
Lorsqu'une équipe opère déjà sur AWS, le choix des outils CI/CD n'est jamais neutre. Les services natifs comme AWS CodePipeline offrent une intégration directe avec les rôles IAM, les VPC, les artifacts S3 et CloudFormation, sans surcharge réseau ni authentification tierce à maintenir. En revanche, des plateformes comme GitLab CI ou GitHub Actions incarnent la convergence 'tout dans Git', réduisant le nombre de points d'authentification et simplifiant l'expérience développeur qui vit déjà sur ces forges. Jenkins, plus ancien et agnostique, permet une liberté maximale mais exige une expertise interne pour exploiter AWS sans y laisser des traces de configuration manuelle.
L'enjeu concret n'est pas 'quel outil est le meilleur' mais 'quel écosystème minimise la friction et la dette technique pour votre équipe spécifique'. Une startup qui a investi dans GitHub depuis le day one ne trouvera aucun intérêt à basculer sur CodePipeline juste parce qu'elle tourne sur AWS. Inversement, une équipe AWS-first avec des pipelines complexes (multi-compte, approbations cross-team, déploiement bleu-vert automatisé) trouvera dans CodePipeline natif une source unique de vérité sans externaliser la logique d'orchestration.
Cette première section pose le prisme clé : l'outil CI/CD idéal n'existe que relativement au contexte de votre équipe (taille, expertise, forges existantes, topologie AWS) et à votre ambition de pipeline (validations légères ou orchestration complexe). Le reste de l'article structure comment évaluer cette pertinence et configurer le choix retenu pour qu'il devienne un multiplier de productivité et non un gouffre de maintenance.
CodePipeline, CodeBuild et CodeDeploy : l'écosystème natif AWS et ses forces
Le trio CodePipeline, CodeBuild, CodeDeploy forme la colonne vertébrale du CI/CD natif AWS. CodePipeline orchestre le workflow, CodeBuild compile et teste votre code, CodeDeploy pousse les artéfacts sur les cibles (EC2, on-premises, Lambda).
La vraie force ici est l'intégration profonde avec l'IAM. Vous ne créez qu'une seule role IAM pour le pipeline ; elle obtient l'accès transparent aux buckets S3 (stockage des artifacts), aux registres ECR, à CloudFormation, au KMS pour le chiffrement. Aucune clé d'accès AWS à externaliser, aucun secret à injecter via des plugins. C'est du credential-less, de facto sécurisé.
Deuxième atout : la flexibilité des étapes. Chaque étape peut appeler une action native (déployer un Lambda, invoquer une fonction Step Functions, exécuter un changeset CloudFormation) ou une action personnalisée (un script shell dans CodeBuild, un appel Lambda custom). Vous composez ainsi des orchestrations complexes sans sortir de l'écosystème AWS. Un pipeline multi-compte pour déployer depuis un compte 'hub' de CI vers des comptes applicatifs isolés devient trivial : IAM cross-account + role assumption dans CodePipeline, done.
Troisième point : la prise en compte native des webhooks GitHub/GitLab/Bitbucket. Un commit sur main déclenche automatiquement le pipeline sans avoir à pollster une URL ou à configurer un runner externe. Pour les équipes qui opèrent déjà sur ces forges, c'est une couture pratique qui évite une couche supplémentaire.
La limite ? CodePipeline n'est pas une interface intuitive pour les débutants. L'éditeur visuel est fonctionnel mais peu flexible ; la plupart du temps, vous écrirez du CloudFormation ou Terraform pour versionner votre pipeline-as-code. CodeBuild en lui-même demande aussi une certaine familiarité avec les buildspecs (fichier YML qui décrit les phases de build) et les rôles IAM. Pas de magie, beaucoup de configuration explicite.
GitHub Actions et GitLab CI : la convergence 'tout en Git' et ses implications opérationnelles
GitHub Actions et GitLab CI renversent l'équation : au lieu d'un outil CI/CD séparé qui consulte votre forge, vous décrivez le workflow directement dans un dossier .github/workflows ou .gitlab-ci.yml versionnés avec votre code. Le pipeline et le code vivent au même endroit.
Pour une équipe distribuée ou une startup qui bouge vite, c'est une bénédiction. Changer la stratégie de test ? Modifier le .yml, ouvrir une PR, reviewer avec le code concerné, merger. Pas besoin d'aller configurer un interface Jenkins ou CodePipeline séparée. La friction est minimale.
GitHub Actions, en particulier, a l'avantage de la maturité : les actions du marché (AWS CLI, Terraform, Docker, Snyk, etc.) sont maintenues par leurs auteurs eux-mêmes, testées à grande échelle, et souvent très bien documentées. Un exemple simple : utiliser l'action 'aws-actions/configure-aws-credentials' pour authentifier automatiquement votre runner sur AWS via OpenID Connect, sans créer de clés d'accès AWS longue durée. C'est une bonne pratique de sécurité rendue triviale.
GitLab CI pousse le modèle même plus loin avec les runners auto-hébergés, les artifacts natifs, et une syntaxe de pipeline particulièrement lisible. Pour les équipes qui utilisent GitLab self-hosted (sur AWS ou ailleurs), GitLab CI devient un outil stratégique, pas seulement une commodité.
La limite de cette approche : le fichier workflow grandit. Les équipes finissent souvent par extraire de la logique en scripts shell ou en actions réutilisables, créant une maintenance secondaire. Aussi, si votre équipe n'est pas déjà sur GitHub ou GitLab (par exemple, vous utilisez Bitbucket), cette convergence perd de son attrait. Et pour les orchestrations multi-compte très complexes ou les approbations cross-team, vous devrez bricoler avec des webhooks, des appels API via actions custom, ce qui perd de l'élégance comparé à CodePipeline natif.
Dernier point : les runners. GitHub Actions propose des runners hébergés par GitHub, gratuits pour les repos publics, payants au-delà d'un seuil pour les privés. GitLab CI propose pareil mais avec la flexibilité des runners auto-hébergés. Si votre code doit s'exécuter en VPC (accès à des bases de données privées, par exemple), un runner hébergé ne suffit pas ; il faut auto-héberger ou utiliser un tunnel VPN, couche supplémentaire de complexité.
Jenkins et autres solutions tiers : quand l'agilité vaut la maintenance
Jenkins reste l'outil historique préféré des équipes qui opèrent Jenkins depuis 5, 10 ou 15 ans. C'est du on-premise, du self-hosted, du 'vous contrôlez tout'. Cela signifie aussi que vous maintenez tout : les updates Jenkins, les plugins, la sécurité du serveur, le chiffrement des credentials, le backup de la configuration.
La vraie force de Jenkins est la flexibilité. Des milliers de plugins permettent d'intégrer n'importe quel service : déployer sur AWS, Kubernetes, Azure, on-prem, envoyer un Slack, valider une PR, invoquer un webhook custom. Si votre équipe a besoin d'orchestrer des systèmes hétérogènes (déploiement partiel on-prem, partiel AWS, avec validations complexes entre les deux), Jenkins peut le faire sans grosse limitation.
Dans un contexte AWS spécifiquement, Jenkins tourne généralement sur une instance EC2 auto-hébergée. Cela pose plusieurs frictions. D'abord, vous hébergez un point unique de défaillance : si le serveur Jenkins plante, tous vos pipelines s'arrêtent. Vous devez donc soit maintenir un cluster Jenkins très robuste (master + agents, chiffrement, backup régulier), soit accepter les downtime. Deuxièmement, vous créez de la dette de maintenance : chaque mise à jour Jenkins, chaque création de slave agent, chaque ajustement de performance devient un travail interne.
Vers 2015-2018, l'industrie a commencé à utiliser CloudBees (Jenkins hébergé dans le cloud) ou GitLab Runner/GitHub Actions pour éliminer cette maintenance. Mais les grandes organisations qui ont investi dans Jenkins on-prem continuent souvent pour des raisons d'inertie, et c'est pas illégitime si l'équipe DevOps a l'expertise pour la maintenir.
Dans la pratique, si vous partez de zéro et opérez sur AWS, choisir Jenkins signifie : vous acceptez une dépense en infrastructure et maintenance pour bénéficier d'une flexibilité que CodePipeline ou GitHub Actions ne vous donnent pas. C'est un trade-off conscient, rarement la 'meilleure option' pour une startup ou une PME.
Configuration pratique et intégration avec AWS, version par version
Une fois l'outil choisi, sa configuration doit suivre les principes d'une bonne hygiène de pipeline : pas de credentials en dur, infrastructure-as-code, logs centralisés, artifacts versionnés.
Avec CodePipeline, vous définissez tout en CloudFormation ou Terraform. Un exemple typique : une Pipeline resource CloudFormation qui spécifie l'étape Source (avec webhook GitHub), l'étape Build (CodeBuild avec un fichier buildspec.yml), l'étape Deploy (CloudFormation changeset). Vous versionez ce template dans Git, reviewez les changements comme du code, et déclenchez la création de la pipeline via un autre pipeline bootstrap. Cela évite les clics manuels et crée une vraie source unique de vérité.
Avec GitHub Actions, vous versionnez directement le .github/workflows/deploy.yml. Un pattern simple : checkout le code, installer les outils (AWS CLI, Terraform, etc.), s'authentifier auprès d'AWS via OIDC (OpenID Connect), exécuter les étapes de build et déploiement. L'OIDC est clé : il élimine le besoin de créer une clé d'accès AWS qui vit dans les GitHub Secrets, source de risque si leakée.
Avec GitLab CI, le .gitlab-ci.yml suit une structure similaire mais avec des stages explicites. Les runners auto-hébergés peuvent tirer des images Docker (ex. aws-cli, terraform) directement depuis ECR privé, ce qui boucle l'expérience 'tout sur AWS'.
Dans tous les cas, trois éléments critiques à verrouiller : (1) Authentification : utiliser des roles IAM cross-account quand possible, OIDC pour GitHub/GitLab, jamais de clés AWS longue durée en secrets. (2) Artifacts : stocker dans un bucket S3 dédié, chiffré KMS, avec une politique de rétention et nettoyage automatique. (3) Logs : rediriger tous les logs de build (CodeBuild, actions, steps) vers CloudWatch ou ELK centralisé, pour audit et débogage post-mortem.
Un dernier point : les approches varient aussi sur le déploiement. CodePipeline s'intègre nativement avec CloudFormation (vous pouvez approuver un changeset avant de l'appliquer), ou avec CodeDeploy si vous préférez une approche basée sur des scripts. GitHub Actions et GitLab CI déploient souvent via des appels à des APIs (Terraform Cloud, ArgoCD, AWS Lambda custom) que vous maintenez. Cela donne plus de contrôle mais exige plus de bricolage.
Le piège courant : choisir l'outil sans penser à l'infrastructure qui le soutient. Un pipeline GitHub Actions qui doit accéder à une base de données RDS en VPC exigera soit d'auto-héberger les runners (surcharge), soit d'utiliser VPN (friction), soit d'exposer la base en public (non, merci). Avec CodePipeline + CodeBuild, vous lancez le build directement dans un VPC subnets, nul problème. Ces détails architecturaux ne sont pas cosmétiques ; ils deviennent des points de friction permanents.
Critères de sélection : comment prioriser selon votre contexte AWS spécifique
Vous avez maintenant une vue de trois univers CI/CD. Comment les hiérarchiser pour votre situation précise ?
Le premier critère est souvent le plus bête : où vit votre code source aujourd'hui ? Si vous avez 20 repos sur GitHub avec des équipes qui vivent dans l'interface GitHub, forcer CodePipeline signifie créer une friction entre 'où je merge mon code' et 'où je vois mon pipeline', deux endroits différents. C'est des aller-retours cognitifs permanents. A contrario, GitHub Actions boucle la boucle. Un seul argument qui justifie souvent une décision à lui seul.
Deuxième critère : la complexité de vos déploiements. Si vous avez un workflow simple (build Docker, push ECR, redéployer une Lambda ou ECS task), n'importe quel outil suffit. GitHub Actions, c'est 30 lignes de YAML lisible. Si vous devez orchestrer des approbations cross-team, des déploiements multi-compte (avec assomption de rôle), une validation par infrastructure-as-code et changeset CloudFormation, des rollbacks automatiques, là CodePipeline natif commence à montrer sa valeur. C'est pas que GitHub Actions ne peut pas faire, c'est que vous écrirez beaucoup de custom logic qui mieux s'exprime en CodePipeline avec ses Actions prêtes.
Troisième critère : l'expertise interne. Si vous avez un VPC complexe, des exigences de compliance strictes, une expérience native AWS approfondie, CodePipeline s'aligne avec votre mental model. Si votre équipe est polyvalente, vit plus sur Docker et Kubernetes, moins affûtée sur AWS IAM/CloudFormation, GitHub Actions est plus proche du 'infrastructure as code' que ces équipes connaissent (Dockerfiles, Helm, YAML Git).
Quatrième critère : la conformité et l'audit. Dans des industries hautement réglementées (finance, santé), CodePipeline peut être plus confortable car il vit entièrement en AWS, donc un seul audit trail AWS CloudTrail suffit. Avec GitHub Actions, vous aurez des logs GitHub, des logs AWS, potentiellement des logs du runner auto-hébergé à croiser lors d'une inspection. Pas impossible, mais plus de surfaces.
Cinquième critère : la flexibilité future. Si votre roadmap inclut à terme du multi-cloud (AWS + Azure, par exemple), GitHub Actions et GitLab CI absorbent mieux cette évolution car ils ne sont pas AWS-natifs. Avec CodePipeline, ajouter une étape déploiement Azure deviendra plus laborieux.
Dans la pratique, voici une matrice de recommandation simple : équipe GitHub-first avec déploiements simples ? GitHub Actions. Équipe AWS-first, déploiements orchestrés, multi-compte ? CodePipeline. Équipe distribuée, legacy complex, besoin d'une flexibilité maximale ? Jenkins self-hosted ou CloudBees. Petite équipe, just-started sur AWS ? GitHub Actions pour la rapidité, migrer à CodePipeline plus tard si l'orchestration devient critique.
Pièges courants et antipatterns dans l'adoption d'outils CI/CD sur AWS
Les équipes qui migrent vers AWS ou qui mettent en place leur premier pipeline sérieux se cognent souvent aux mêmes erreurs.
Premier piège : oublier que l'outil ne fait que l'orchestration. Si votre buildspec.yml ou votre GitHub Actions workflow contient des 'aws s3 cp' manuels, des clés AWS secrets en dur, ou du bash complexe pour faire un 'vrai' déploiement, vous n'avez pas un pipeline robuste, vous avez un script fragile caché dans un outil CI/CD. Les bonnes pratiques (infrastructure-as-code via Terraform ou CloudFormation, dépôts versionnés, approbations explicites) doivent porter le poids du déploiement, pas le script CI/CD. L'outil doit être mince, orchestrant des abstractions d'ordre supérieur.
Deuxième piège : les logs qui s'égarent. Un build CodeBuild écrit des logs CloudWatch, mais quand quelque chose pète à 3h du matin, vous devez creuser CloudWatch, puis voir les logs CodeDeploy séparés, puis lire les logs applicatifs ECS/Lambda. Presque personne n'émet les logs d'un pipeline dans un seul endroit. La solution : définir une convention dès le départ. Tous les logs de pipeline et build vont à un index ElasticSearch ou CloudWatch Logs centralisant (pas juste CloudWatch default), queryable et avec alertes. Vous économisez des heures de débogage plus tard.
Troisième piège : les credentials qui fuient. Une clé AWS hardcodée dans un buildspec.yml commitée par accident, un secret GitHub exposé en public, un token Jenkins dans un log de build visible. Avec OIDC (GitHub Actions) ou les roles IAM cross-account (CodePipeline), ces fuites deviennent inutiles. Mais beaucoup d'équipes ne savent pas que cette option existe et continuent à générer des clés longue durée. Éducation claire : jamais de secrets AWS longs termes dans un pipeline. Les seuls secrets permis sont les patterns temporaires (assomption de rôle STS) ou les identifiants d'outils tiers qui ne vendent pas AWS credentials (Slack webhook, registry token privé, etc.).
Quatrième piège : ignorer la scalabilité du runner ou du build executor. Si vous avez un seul serveur Jenkins et 50 équipes qui mergent du code, ou un seul GitHub Actions self-hosted runner, vous créez un goulot. CodeBuild scale nativement (AWS gère des centaines de builds concurrents sans effort), GitHub Actions hébergés idem. Mais si vous auto-hébergez (Jenkins, GitLab Runner), vous devez planifier la capacité. Beaucoup d'équipes ne se posent cette question que quand le pipeline est devenu trop lent.
Cinquième piège : le 'pipeline magique'. Au départ, c'est simple : commit déclenche test, test passe, déploiement auto en staging. Mais au fil du temps, vous rajoutez de l'orchestration : 'aller chercher une licence depuis un serveur central', 'demander une approbation Slack', 'attendre un événement externe', 'dérouler un script de migration BDD', 'notifier 5 services'. Petit à petit, le pipeline devient un monstre complexe qui coûte plus de maintenance que tout le code applicatif. La solution : tracer une ligne clé. Le pipeline décrit le 'quoi' et le 'quand' (build, test, déployer en staging/prod). Le 'comment' (les scripts, les migrations, les intégrations) doit être déporté en infrastructure-as-code ou en scripts versionnés que le pipeline appelle, jamais embédé dans le YAML du pipeline.
Sixième piège : oublier les rollbacks. Vous déployez en prod, quelque chose casse. Votre pipeline n'a aucun mécanisme de rollback automatique car 'on pensait que ça ne pouvait pas casser'. Avec CodePipeline, vous pouvez paramétrer des rollbacks automatiques basés sur des CloudWatch alarms (si le taux d'erreur Lambda passe au-dessus de X%, rollback la dernière version). Avec GitHub Actions, c'est plus manual (vous appelez un autre workflow qui revert le déploiement). Mais de facto, tout pipeline sérieux doit avoir un chemin 'revert' aussi rapide que 'forward'.
Logs centralisés et auditables, la base oubliée
La majorité des équipes se rend compte trop tard que leurs logs de pipeline sont une vraie plaie à déboguer. CodeBuild envoie les logs à CloudWatch Logs par défaut, mais les logs CodeDeploy vont ailleurs, les logs Lambda d'application dans un groupe CloudWatch différent, et les logs du runner GitHub Actions sur GitHub lui-même. Quand vous cherchez 'pourquoi le déploiement de ce commit a échoué', vous devez sauter entre plusieurs interfaces.
Une vraie solution : décider d'une source unique. Par exemple, tous les événements pipeline vont dans un stream CloudWatch Logs centralisé via une Lambda qui écoute les événements CodePipeline, ou un EventBridge rule qui les agrège. Les logs de build, au lieu d'aller dans CloudWatch default, vont via CloudWatch Logs forwarder vers un cluster ElasticSearch (ou OpenSearch) où ils sont queryable par commit SHA, pipeline ID, équipe. Cette infrastructure de logging doit être en place le jour 1, pas rajoutée avec urgence en prod.
Avec GitHub Actions, vous pouvez ajouter une action finale qui pousse tous les logs vers CloudWatch ou S3, ce qui boucle le schéma centralisé.
Le coût de ce reflex : une ou deux journées d'ingénierie. Le bénéfice : des heures économisées chaque mois en débogage et compliance.
Paramétrage d'authentification : OIDC plutôt que secrets longue durée
Une question revient sans cesse : comment mon pipeline sur GitHub/GitLab obtient-il les credentials AWS pour déployer ?
L'ancienne réponse (encore trop courante) : créer une clé d'accès AWS et la stocker dans GitHub Secrets ou les variables GitLab CI. Fonctionnel, mais le risque est réel. Si le repo devient public par accident, si un développeur lite les logs, si le secret s'expose par mistake dans un commit, la clé traîne sur le web.
La bonne réponse : OpenID Connect (OIDC). GitHub et GitLab peuvent émettre des tokens OIDC identifiant chaque run. Au lieu d'utiliser une clé AWS, votre pipeline utilise ce token OIDC pour demander une credential temporaire AWS via STS AssumeRoleWithWebIdentity. La credential vaut 15 minutes par défaut, puis expire. Pas de secret long terme à protéger.
La setup : vous créez un IAM Identity Provider pour GitHub (ou GitLab) pointant vers 'token.actions.githubusercontent.com' (ou l'équivalent GitLab). Puis une role IAM avec une policy de trust qui accepte les tokens OIDC émis par GitHub pour votre repo. Dans votre workflow, au lieu de chercher des credentials AWS, vous appelez l'action 'aws-actions/configure-aws-credentials@v2' avec les paramètres role-to-assume et web-identity-token-file. L'action magie se fait, vous obtenez une credential temporaire, et votre pipeline peut faire 'aws s3 cp' sans jamais toucher une clé.
C'est plus sûr, plus limité en scope (la role peut être très restrictive 'déploier seulement sur ce compte/cette région'), et plus facile à auditer (CloudTrail vous montre une assomption de rôle SourceArn spécifique par run GitHub, pas une clé floue générique).
Quasiment aucune équipe n'utilise OIDC par défaut. Beaucoup ne savent pas que ça existe. C'est un gain facile de sécurité qui prend un jour à mettre en place et sauve potentiellement des incidents plus tard.