Slack, GitHub, Jira : intégrer sans créer un patchwork

Le patchwork arrive plus vite que prévu

Vous commencez avec un canal Slack. Puis un dépôt GitHub. Puis un projet Jira parce qu'un client l'exige. Six mois plus tard, votre équipe reçoit des notifications de quatre outils pour la même tâche, et personne ne sait plus où se trouve la vérité.

Ce n'est pas un problème d'outils. C'est un problème de flux. Une intégration utile relie une action à une décision. Une intégration inutile ajoute une notification que quelqu'un finira par couper.

La question à se poser avant de brancher quoi que ce soit : qui doit savoir quoi, à quel moment, et pour faire quoi ? Si vous n'avez pas de réponse claire, l'intégration va créer du bruit.

Ce que les intégrations coûtent vraiment

Une intégration n'est pas gratuite. Elle ajoute une dépendance entre deux systèmes, et donc une surface de panne. L'incident GitHub du 5 juin 2026 en donne un exemple concret.

Ce jour-là, entre 15h35 et 16h45 UTC, 0,11 % des requêtes REST authentifiées ont renvoyé à tort une réponse « not found ». L'impact s'est concentré sur les jetons user-to-server accédant à des dépôts d'organisation. Conséquence inattendue : certains utilisateurs des intégrations GitHub pour Slack et Microsoft Teams ont vu leurs abonnements de canaux supprimés, les systèmes ayant interprété cette erreur transitoire comme une perte d'accès durable.

Environ 12 % des organisations avec des abonnements actifs ont été touchées, et près de 2 % de tous les abonnements de canaux ont été supprimés. GitHub a désactivé le drapeau de fonctionnalité fautif à 16h45 UTC, puis restauré les abonnements à 22h21 UTC. L'entreprise indique travailler à ajouter une logique de nouvelle tentative et de période de grâce pour que les erreurs transitoires ne déclenchent plus de suppressions.

« We are working to add retry and grace-period logic in the chat integrations so transient errors no longer trigger subscription deletions. » — GitHub Status, 5 juin 2026

À retenir : une intégration de chat qui dépend d'une API tierce peut casser sans que vous ayez rien changé. Ce n'est pas une raison pour tout débrancher, mais c'est une raison pour ne pas en empiler dix.

Trois critères pour trier vos intégrations

Avant d'ajouter une connexion, passez-la sur ces trois questions.

1. Quelle décision cette notification déclenche-t-elle ?

Si la réponse est « aucune, c'est juste pour info », coupez. Une notification qui ne mène à aucune action est un coût sans retour.

2. Où vit la vérité ?

Une tâche doit avoir un seul domicile. Si elle existe à la fois dans Jira, dans un canal Slack et dans un tableau GitHub, vous avez trois versions et zéro vérité. Choisissez l'outil qui porte le travail, et laissez les autres notifier.

3. Qui reçoit, et à quelle fréquence ?

Un canal par projet, pas un canal par outil. Un résumé quotidien vaut souvent mieux que vingt messages en temps réel. Les webhooks sont utiles ici : ils vous laissent choisir l'événement et le format, au lieu de subir le comportement par défaut d'une intégration clé en main.

Slack, Teams, GitHub, Jira, Notion : quoi brancher, quoi éviter

Toutes les intégrations ne se valent pas. Voici une lecture par usage, pas par popularité.

Slack et Microsoft Teams

Utiles pour : les alertes qui exigent une réaction humaine rapide (incident, blocage, revue en attente). À éviter : le miroir automatique de chaque changement de statut. Personne ne lit cinquante messages « carte déplacée ».

GitHub

Utile pour : lier une pull request à une user story, voir l'avancement réel du code sans quitter le projet. À surveiller : comme le montre l'incident de juin 2026, les abonnements de canaux peuvent être perdus lors d'erreurs API. Vérifiez périodiquement que vos canaux sont toujours abonnés.

Jira

Utile si un client ou un partenaire impose Jira. Dans ce cas, synchronisez le strict nécessaire : statut et assignation, pas les commentaires ni les pièces jointes. Sinon vous entretenez deux backlogs.

Notion

Utile pour la documentation qui doit rester lisible par des non-techniques. Moins utile comme second gestionnaire de tâches : vous recréez le problème que vous vouliez résoudre.

Webhooks

Le filet de sécurité. Un webhook vous laisse décider quel événement part, vers où, et sous quelle forme. C'est l'option à privilégier quand une intégration native envoie trop ou pas assez.

Garder une source de vérité unique

La règle est simple à énoncer et difficile à tenir : un seul outil porte le travail, les autres le reflètent. Le backlog, les sprints, les user stories, les critères d'acceptation vivent au même endroit. Slack informe. GitHub exécute. Notion documente.

Concrètement, cela veut dire accepter que certains outils ne soient pas synchronisés dans les deux sens. Une synchronisation bidirectionnelle entre deux gestionnaires de projet produit toujours des conflits, des doublons et des champs qui divergent. Une synchronisation à sens unique, du lieu de vérité vers le lieu de notification, est plus fragile en apparence mais plus fiable en pratique.

Ever Earlier se connecte à Slack, Microsoft Teams, GitHub, Jira, Notion et via webhooks. L'usage typique : une user story vit dans Ever Earlier avec sa priorité, ses points et ses critères d'acceptation ; la pull request GitHub qui la ferme remonte l'information dans le tableau Kanban, et le canal Slack du projet reçoit une seule notification quand la story passe en revue. Pas de doublon, pas de second backlog.

Checklist avant de brancher une nouvelle intégration

Reprenez cette liste chaque fois qu'un outil vous propose une connexion.

1. Nommez la décision que la notification doit déclencher. Si vous ne pouvez pas, refusez.
2. Vérifiez que la tâche n'existe pas déjà ailleurs. Un doublon aujourd'hui devient un conflit demain.
3. Choisissez le canal de destination : un canal par projet, pas un canal par outil.
4. Réglez la fréquence : temps réel seulement pour ce qui est urgent, résumé sinon.
5. Prévoyez ce qui se passe si l'intégration tombe. Qui s'en aperçoit ? Au bout de combien de temps ?
6. Documentez en une ligne où vit la vérité pour ce type de tâche.

Cette dernière étape est celle que les équipes sautent le plus souvent. C'est aussi celle qui évite le patchwork.