Le devops avant GitHub, ce n'était pas une préhistoire pittoresque : c'était Subversion, des scripts de déploiement bricolés à la main et des mises en production qui finissaient rarement à l'heure prévue. La vraie différence entre alors et maintenant tient moins à GitHub lui-même qu'à ce qu'on a appris sur la coordination d'équipe. Comprendre cette histoire aide à voir ce que l'automatisation a réellement résolu, et ce qu'elle n'a jamais résolu.
- 📈 SVN avant Git, le contrôle de version décentralisé a précédé GitHub de plusieurs années.
- ⚠️ Déploiements manuels, avant le CI/CD généralisé, chaque mise en production dépendait d'un humain et d'un script maison.
- 💡 GitOps depuis 2017, Git devient la source unique de vérité pour l'infra, pas seulement pour le code applicatif.
- 🚀 L'outil ne fait pas l'ingénieur, l'automatisation réduit la friction opérationnelle, pas le besoin de jugement technique.
Ça peut sembler être un sujet d'archéologie logicielle. Ce n'en est pas un : les mêmes erreurs de coordination réapparaissent aujourd'hui, simplement maquillées derrière des pipelines YAML.
Le DevOps existait bien avant GitHub, et c'était un cauchemar de coordination
Un développeur a posé la question sur r/ExperiencedDevs en demandant à ceux qui travaillaient avant GitHub et les outils DevOps modernes comment se passait leur quotidien. Un post quasi identique est apparu sur r/developersIndia, preuve que la question dépasse une génération ou une géographie précise. Le constat de départ, dans les deux fils, est le même : gérer les branches, les fusions, les builds et les déploiements avec Subversion ou Tortoise SVN demandait une coordination lourde et beaucoup d'effort opérationnel manuel.
Avant l'automatisation, une mise à jour de serveur se faisait souvent à la main, une configuration se modifiait directement en production, et un script s'exécutait sans filet. J'ai vu cette époque de loin en début de carrière, et le symptôme numéro un n'était pas la lenteur : c'était l'imprévisibilité. Deux environnements censés être identiques finissaient toujours par diverger, sans que personne ne sache exactement pourquoi.
Comment on déployait une application avant Git et le CI/CD ?
Le déploiement reposait sur une combinaison de mise à jour manuelle des serveurs, de modification directe des configurations et d'exécution de scripts ad hoc, sans automatisation centralisée. Revenir à une version antérieure en cas de problème était complexe et risqué, faute d'un historique fiable et versionné. La dérive de configuration entre environnements de développement, de test et de production était un problème récurrent, difficile à diagnostiquer parce que personne n'avait de vue d'ensemble claire de l'état réel du système.
GitOps a changé les règles du jeu à partir de 2017
Cette friction manuelle est précisément ce que GitOps a attaqué. Le concept a été introduit en 2017 par Weaveworks, comme le rappelle un tutoriel de la chaîne Thinknyx Technologies consacré au sujet. L'idée centrale : traiter l'infrastructure, la configuration et les politiques opérationnelles comme du code, stocké dans un dépôt Git qui devient la source unique de vérité du système.
Concrètement, un développeur pousse une modification dans le dépôt. Un outil comme Argo CD, GitHub Actions ou Jenkins surveille ce dépôt et applique automatiquement le changement à l'infrastructure cible. Le système reste en permanence synchronisé avec l'état décrit dans Git, ce qui rend les déploiements plus prévisibles et les retours en arrière aussi simples qu'un retour à un commit antérieur.
Qu'est-ce que le déploiement push et le déploiement pull en GitOps ?
Dans un déploiement push, un pipeline automatisé, souvent Jenkins, envoie activement les modifications du dépôt vers l'environnement cible dès qu'un commit est détecté. Dans un déploiement pull, un agent qui tourne dans l'environnement, comme Argo CD, surveille en continu le dépôt et récupère lui-même les changements pour ajuster l'infrastructure. La différence paraît technique, mais elle change qui déclenche le changement : le pipeline dans un cas, l'environnement lui-même dans l'autre.
Le marché des outils CI/CD et d'automatisation d'infrastructure continue de croître à deux chiffres chaque année, une tendance que les cabinets d'analystes comme Gartner suivent de près sous l'angle de la consolidation des plateformes DevOps. GitHub, de son côté, n'est arrivé que tardivement sur ce terrain. Selon un comparatif publié par journaldunet.com, GitLab intègre une brique CI/CD dès 2012, alors que GitHub, racheté par Microsoft en 2018, ne se positionne sur ce terrain qu'à la fin de l'année 2019 avec le lancement des Actions. Le nom qui domine aujourd'hui l'imaginaire du DevOps n'est donc pas celui qui a inventé la discipline. Il l'a rattrapée.
L'automatisation résout la friction, pas le jugement technique
Là où je décroche un peu du discours ambiant sur le sujet, c'est sur l'idée que GitOps ou GitHub Actions auraient réglé le problème du DevOps une bonne fois pour toutes. Ils ont réglé un problème précis : la dérive de configuration et l'absence de traçabilité. Ils n'ont jamais réglé la question de savoir si l'architecture derrière le pipeline avait du sens.
Un pipeline CI/CD parfaitement configuré peut déployer une mauvaise architecture avec une fiabilité redoutable. C'est même pire qu'avant, dans un sens : la vitesse d'exécution masque plus longtemps les mauvais choix de conception. Un déploiement manuel raté se voyait tout de suite. Un mauvais choix d'architecture automatisé peut tenir des mois avant que la facture n'arrive, souvent sous forme de dette technique ou d'incident en cascade.
Pourquoi un bon pipeline CI/CD ne remplace jamais un ingénieur senior ?
Un pipeline exécute ce qu'on lui a dit d'exécuter, il ne questionne jamais si c'est la bonne chose à exécuter. La décision de séparer un monolithe, de choisir une base de données, de dimensionner un cluster ou d'arbitrer entre régie et forfait reste un jugement humain, qu'aucun outil d'automatisation n'a vocation à porter. C'est un problème d'architecture et de responsabilité, pas un problème d'outillage.
C'est exactement ce que je constate avec les outils IA appliqués au développement : ils accélèrent l'exécution d'une décision, jamais la décision elle-même. Un développeur qui utilise Claude Code ou Cursor reste un ingénieur qui doit comprendre le besoin métier, pas un opérateur de prompt qui espère que le résultat tienne en production.
GitHub, GitLab, Cycloid : le choix de plateforme compte moins que l'équipe qui l'utilise
Le comparatif de journaldunet.com, réalisé sur les plateformes DevOps intégrées du marché français et international, donne une bonne photographie de qui couvre quoi. GitLab ressort comme la solution la plus complète nativement, GitHub reste fort sur l'écosystème et la sécurité, et Cycloid, acteur français, se positionne sur l'infrastructure as code multi-cloud.
| Critère | GitHub | GitLab | Cycloid |
|---|---|---|---|
| Git intégré / suivi des bugs | Oui | Oui | Non |
| IaC multi-cloud | Non | Oui | Oui |
| Gestion de configuration | Non | Oui | Oui |
| CI/CD natif | Oui (Actions) | Oui (GitLab CI) | Oui |
| Designer d'infrastructure | Non | Non | Oui |
SOURCE : journaldunet.com, comparatif des plateformes DevOps · MAJ 07/2021
Le tableau donne une réponse claire sur le papier. Dans la pratique, j'ai vu des équipes tirer un excellent résultat d'une stack GitHub minimaliste, et d'autres s'enliser sur une stack GitLab complète parce que personne dans l'équipe ne maîtrisait vraiment l'infrastructure as code. La plateforme fixe le plafond de ce qui est possible. Elle ne garantit jamais que l'équipe l'atteindra.
Ce que ça change pour une équipe offshore augmentée à l'IA
Transparence : je dirige une ESN offshore au Vietnam, donc j'ai un biais évident sur ce sujet, c'est aussi pour ça que je vois de près où l'automatisation aide vraiment et où elle ne sert qu'à rassurer un board sur PowerPoint. L'équation que je défends n'est pas nouvelle, mais le GitOps et l'IA générative la rendent plus lisible qu'avant : une petite équipe senior, bien outillée, qui maîtrise à la fois le pipeline et l'architecture derrière, bat une équipe deux fois plus grande qui empile des outils sans comprendre pourquoi.
En mai 2026, un client parisien m'a montré son pipeline GitHub Actions vieux de six ans, jamais retouché depuis l'audit de sécurité qui l'avait mis en place. L'outil fonctionnait toujours. L'architecture qu'il déployait, elle, avait accumulé assez de dette technique pour justifier une reprise complète. Le GitOps n'avait rien empêché : il avait simplement rendu la dette invisible plus longtemps.
L'avantage d'une équipe vietnamienne senior augmentée à l'IA ne vient pas d'un outil DevOps particulier, il vient de la combinaison entre compétence d'architecture et vitesse d'exécution. J'ai déjà détaillé comment cette combinaison se traduit en économies concrètes dans un article sur les gains réels d'une équipe offshore équipée de Claude Code. Le même principe s'applique au DevOps : le pipeline le plus moderne du marché ne sauve jamais un projet dont personne ne maîtrise l'infrastructure de bout en bout, et le code généré par IA pose exactement cette question de responsabilité quand un déploiement automatisé pousse en production une erreur qu'un humain aurait détectée en cinq minutes.
Le devops moderne récompense les équipes qui savent encore lire un pipeline ligne par ligne, pas seulement celles qui savent en configurer un à partir d'un template. C'est vrai avec GitOps depuis 2017, et ça reste vrai avec l'IA en 2026.
« L'automatisation n'a jamais remplacé le jugement d'un bon ingénieur. Elle a juste changé où on le dépense. »
Vincent Roye, Août 2026
Le fil rouge de cette histoire, du SVN d'avant-GitHub jusqu'aux agents IA d'aujourd'hui, tient en une phrase : chaque génération d'outils promet de régler le problème humain du DevOps, et chaque génération finit par déplacer ce problème un cran plus loin. Ce n'est pas un échec des outils. C'est juste leur rôle réel.
Le verdict : le DevOps avant GitHub explique pourquoi les équipes gagnent encore sur le jugement, pas sur l'outil
Non, GitHub n'a pas inventé le DevOps, et le devops avant GitHub n'était pas simplement une version plus lente de celui d'aujourd'hui : c'était une discipline qui reposait presque entièrement sur la discipline humaine, faute de garde-fous automatisés. Le GitOps a apporté ces garde-fous à partir de 2017, et c'est un vrai progrès. Mais un garde-fou empêche de tomber, il ne choisit pas la direction.
Pour une équipe qui recrute ou externalise sa capacité DevOps en 2026, la question à poser n'est plus « quel outil utilisez-vous ? ». C'est « qui, dans l'équipe, comprend pourquoi ce pipeline a été construit ainsi ». Si personne ne sait répondre, aucune plateforme, aussi complète soit-elle, ne réglera le problème à la place.
Foire aux questions
Le DevOps existait-il vraiment avant GitHub ?
Oui. Les pratiques DevOps de gestion de configuration, de contrôle de version et de déploiement existaient avec des outils comme Subversion, Ansible ou Jenkins bien avant que GitHub ne devienne un acteur central. GitHub a rejoint ce terrain tardivement, avec le lancement de GitHub Actions fin 2019.
Qu'est-ce que le GitOps et en quoi diffère-t-il du DevOps classique ?
Le GitOps est une pratique introduite en 2017 qui utilise Git comme source unique de vérité pour l'infrastructure et les applications, pas seulement pour le code. Contrairement au DevOps classique où les scripts de déploiement pouvaient être exécutés manuellement, le GitOps automatise l'application des changements dès qu'un commit est détecté dans le dépôt.
GitHub, GitLab ou Cycloid : quelle plateforme choisir pour une équipe DevOps ?
GitLab couvre nativement le plus large périmètre fonctionnel, de la gestion de configuration à l'infrastructure as code. GitHub reste la référence pour l'écosystème et la sécurité du code, tandis que Cycloid, acteur français, se distingue sur l'infrastructure as code multi-cloud. Le bon choix dépend surtout de la maturité technique de l'équipe qui va exploiter la plateforme au quotidien.
L'automatisation DevOps réduit-elle vraiment le besoin de développeurs seniors ?
Non, elle déplace ce besoin plutôt qu'elle ne le supprime. Un pipeline automatisé exécute fidèlement les décisions d'architecture qu'on lui a confiées, il ne les questionne jamais. La compétence humaine reste nécessaire pour concevoir cette architecture, diagnostiquer une dérive et arbitrer les choix techniques qu'aucun outil ne peut faire à la place d'un ingénieur.
Pourquoi une équipe offshore augmentée à l'IA a-t-elle un avantage sur le DevOps moderne ?
Parce que l'avantage ne vient pas d'un outil DevOps spécifique mais de la combinaison entre compétence d'architecture et vitesse d'exécution permise par l'IA. Une équipe senior qui maîtrise à la fois le pipeline et ce qu'il déploie tire un bénéfice réel de l'automatisation, alors qu'une équipe qui empile des outils sans les comprendre se contente de déplacer sa dette technique plus loin dans le temps.
Vidéos YouTube
Discussions Reddit
- Developers who worked before GitHub and modern DevOps tooling — r/ExperiencedDevs
- How hard was software development before GitHub and modern DevOps tools? — r/developersIndia
