Pourquoi nous avons consolidé l'ensemble de notre plateforme de développement sur GitHub – et ce que cela signifie pour nos clients.
Nous avons consolidé l’ensemble de notre infrastructure de développement sur GitHub. Dans cet article, nous expliquons pourquoi nous avons franchi ce pas et quels avantages en découlent.
Au fil des années, différents outils se sont accumulés chez nous – comme dans beaucoup d’entreprises. Le code source se trouvait sur Azure DevOps, la planification de projet et la gestion des issues passaient par Taiga, et pour les processus internes, nous avions un intranet propre avec un tableau d’issues développé en interne. Trois plateformes, trois logins, trois endroits où se trouvaient les informations.
Cela fonctionnait – mais c’était fragmenté. Les signalements d’erreurs des clients atterrissaient dans l’intranet, les tâches dans Taiga, le code associé dans Azure DevOps. Qui voulait avoir une vue d’ensemble devait jongler entre trois systèmes. Et quand une personne de contact était absente, on ne savait souvent plus où quel état était documenté.
Quand Taiga a annoncé qu’il allait être remanié et devenir payant, cela a été le déclic pour repenser fondamentalement la situation. Non pas comme réaction à un seul outil – mais comme une chance de faire radicalement le ménage.
Au lieu de remplacer Taiga par le prochain outil, nous avons posé la question autrement : Et si nous n’avions besoin que d’une seule plateforme ?
GitHub peut aujourd’hui bien plus qu’héberger du code. Avec GitHub Actions pour le CI/CD, GitHub Projects pour la planification de projet et GitHub Issues pour la gestion des erreurs, il couvre tout ce que nous avions réparti sur trois systèmes. La décision était claire :
Une plateforme pour tout.
La différence décisive : GitHub offre une intégration IA qui n’existe tout simplement pas chez Azure DevOps. GitHub Copilot est aujourd’hui profondément intégré dans l’ensemble de la plateforme – de la complétion de code aux revues de pull requests et résumés automatisés jusqu’au Copilot Chat directement dans le dépôt. Claude, notre modèle d’IA préféré, s’intègre également de manière fluide dans les workflows GitHub.
Qui veut sérieusement intégrer l’IA dans le processus de développement ne peut pas contourner GitHub. Azure DevOps n’offre ici aucune solution comparable.
Avec GitHub Projects, nous pouvons planifier et suivre des tâches, des issues et des jalons à travers plusieurs dépôts dans une seule vue d’ensemble. C’est crucial pour nous en tant qu’entreprise avec plusieurs projets en parallèle. Nous voyons d’un coup d’œil où en est chaque projet – sans devoir naviguer entre différents backlogs.
GitHub est la plus grande plateforme de développement au monde – et ce n’est pas sans raison. La vitesse d’innovation est impressionnante : GitHub Actions, Codespaces, Advanced Security, Dependabot, GitHub Projects v2 – ces dernières années, GitHub a massivement élargi son offre. Parallèlement, le développement d’Azure DevOps a sensiblement ralenti.
Nous voulons travailler avec des outils qui sont activement développés et qui définissent les standards de demain.
C’était l’un des moteurs les plus importants : Les signalements d’erreurs doivent être clairement saisissables, traçables et indépendants des personnes. Dans l’ancien système, les issues étaient liées à des processus internes et des personnes de contact. Quand quelqu’un était en vacances ou malade, le contexte se perdait.
Sur GitHub, chaque issue est documentée de manière transparente – avec historique, attributions et statut. Les clients peuvent saisir directement les erreurs et souhaits, suivre la progression à tout moment et voir ce qui se passe. Pas de dépendance envers des personnes individuelles, pas de boîte noire.
GitHub n’est pas seulement un outil de développement, mais aussi une carte de visite. Nos dépôts publics, notre activité et notre façon de travailler sont visibles pour les clients et partenaires. Cela crée la confiance. Azure DevOps et notre intranet étaient à cet égard des mondes fermés.
La migration n’était pas une décision purement technique – elle fait partie d’une stratégie de plateforme consciente :
Pour vous en tant que client, une chose change surtout : La collaboration devient plus directe et transparente. Vous pouvez saisir des erreurs et des souhaits directement comme GitHub Issues, consulter le statut de vos demandes à tout moment et communiquer directement avec notre équipe de développement si nécessaire – indépendamment de qui est actuellement au bureau.
Si vous n’avez pas encore travaillé avec GitHub – pas de problème. Dans notre article Les bases du Markdown nous vous montrons tout ce dont vous avez besoin pour saisir et formater des issues.
Rendez-nous visite sur GitHub – vous y verrez comment nous travaillons et pourrez collaborer directement avec nous sur votre projet.
En résumé : Moins d’outils, plus de visibilité, une gestion transparente des erreurs – c’est notre promesse avec le passage à GitHub.