[{"data":1,"prerenderedAt":46},["ShallowReactive",2],{"doc:fr:integrations":3},{"title":4,"lede":5,"html":6,"headings":7},"Jira, Trello, GitHub et Linear","Escouade importe les tickets de Jira, Trello, GitHub Issues et Linear dans le Kanban, avec leurs critères d’acceptation, puis tient leur statut à jour et y laisse des commentaires au fil du travail. Cette page couvre la connexion, l’import et la synchronisation.","\u003Cp>\u003Cimg src=\"\u002Fimages\u002Fintegrations.jpg\" alt=\"La fenêtre « Importer des tickets » : des tickets Jira filtrés par « Assignés à moi », avec leurs critères détectés\" width=\"1920\" height=\"960\" loading=\"lazy\" decoding=\"async\">\u003C\u002Fp>\n\u003Ch2 id=\"connecter-un-service\">Connecter un service\u003C\u002Fh2>\n\u003Cp>Les comptes se connectent dans Réglages › Intégrations, groupe « Comptes connectés » (voir \u003Ca href=\"\u002Fdocs\u002Fsettings-integrations\u002F\">Réglages des intégrations\u003C\u002Fa>). Pour chaque service, « Connecter… » ouvre un formulaire. « Connecter » vérifie les identifiants auprès du service (« Vérification… »), puis la ligne dit « Connecté · » suivi de qui tu es chez lui (par exemple \u003Ccode>ada@atlas.dev · atlas.atlassian.net\u003C\u002Fcode>). Si le service refuse, la raison s’affiche sous le formulaire. La connexion est enregistrée tout de suite : elle ne passe pas par « Enregistrer ».\u003C\u002Fp>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Service\u003C\u002Fth>\n\u003Cth>Ce que tu donnes\u003C\u002Fth>\n\u003Cth>Où l’obtenir\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Jira\u003C\u002Ftd>\n\u003Ctd>« Site » (\u003Ccode class=\"key\">atlas.atlassian.net\u003C\u002Fcode>, en https), « E-mail » et « Jeton d’API »\u003C\u002Ftd>\n\u003Ctd>« Créer un jeton d’API Atlassian »\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Trello\u003C\u002Ftd>\n\u003Ctd>« Clé d’API » et « Jeton »\u003C\u002Ftd>\n\u003Ctd>« Obtenir une clé d’API », puis « Obtenir un jeton pour cette clé » (disponible une fois la clé saisie : un jeton en lecture et écriture, sans expiration)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>GitHub\u003C\u002Ftd>\n\u003Ctd>« Jeton », facultatif\u003C\u002Ftd>\n\u003Ctd>« Créer un jeton GitHub ». Laissé vide, Escouade utilise celui de la CLI \u003Ccode class=\"key\">gh\u003C\u002Fcode> (\u003Ccode>gh auth login\u003C\u002Fcode>) ; le compte s’affiche alors avec « · via gh »\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Linear\u003C\u002Ftd>\n\u003Ctd>« Clé d’API »\u003C\u002Ftd>\n\u003Ctd>« Créer une clé d’API Linear »\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>« Déconnecter » oublie le compte et ses secrets. Les projets gardent leurs liens, inutilisés jusqu’à une nouvelle connexion.\u003C\u002Fp>\n\u003Ch3 id=\"ou-sont-gardes-les-jetons\">Où sont gardés les jetons\u003C\u002Fh3>\n\u003Cp>Les jetons restent sur ta machine, à part des réglages, et ne servent qu’aux appels de ces services. Escouade les range dans le trousseau du système : le Gestionnaire d’identification sous Windows, le Trousseau d’accès sous macOS. Sous Linux, qui n’a pas de trousseau pris en charge, ils restent dans \u003Ccode>~\u002F.escouade\u002Fintegrations.json\u003C\u002Fcode>, lisible par toi seul.\u003C\u002Fp>\n\u003Cp>Quand le trousseau refuse un jeton sous Windows ou macOS, il reste dans ce fichier et l’onglet le dit : « Trousseau du système indisponible : le jeton reste dans ~\u002F.escouade\u002Fintegrations.json. » Si le trousseau existe mais ne peut pas être lu, l’onglet dit « Trousseau du système illisible : relance Escouade ou reconnecte le compte. » et aucun appel ne part sans les jetons. Pour GitHub par \u003Ccode class=\"key\">gh\u003C\u002Fcode>, Escouade ne garde aucun jeton.\u003C\u002Fp>\n\u003Ch2 id=\"lier-un-projet-a-une-source\">Lier un projet à une source\u003C\u002Fh2>\n\u003Cp>Un projet se lie à un endroit par service : un projet Jira, un tableau Trello, un dépôt GitHub ou une équipe Linear. Dans Réglages › Intégrations, le groupe « Sources liées à \u003Ccode class=\"key\"><projet>\u003C\u002Fcode> » propose, pour chaque service connecté, une liste : « Projet Jira », « Tableau Trello », « Dépôt GitHub Issues », « Équipe Linear ». « Aucun » délie le service. Pour GitHub, le dépôt du projet, quand son remote est sur GitHub, vient en premier (« (dépôt du projet) »).\u003C\u002Fp>\n\u003Cp>Choisir une source charge ses statuts et pré-remplit la correspondance des statuts (voir plus bas). Enregistre ensuite les réglages.\u003C\u002Fp>\n\u003Cp>Depuis le Kanban, « Importer » sans source liée affiche « Aucune source liée à ce projet » et « Lier une source », qui ouvre ce même onglet.\u003C\u002Fp>\n\u003Ch2 id=\"importer-des-tickets\">Importer des tickets\u003C\u002Fh2>\n\u003Cp>Dans le \u003Ca href=\"\u002Fdocs\u002Fboard\u002F\">Kanban\u003C\u002Fa>, « Importer » (⤓) ouvre la fenêtre « Importer des tickets ». Elle verse les tickets choisis à la fin de « À faire ».\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Un onglet par source liée et connectée (le service, le nom de la source, et le nombre de tickets que tu y as choisis). « ⚙ Gérer les sources » ouvre les réglages.\u003C\u002Fli>\n\u003Cli>Le champ de recherche cherche dans la source choisie. La recherche part 300 ms après la dernière frappe.\u003C\u002Fli>\n\u003Cli>Les puces de filtre se cliquent pour s’activer ou se retirer. Le champ et les puces dépendent du service :\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Service\u003C\u002Fth>\n\u003Cth>Champ de recherche\u003C\u002Fth>\n\u003Cth>Puces\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Jira\u003C\u002Ftd>\n\u003Ctd>« Rechercher par clé ou par texte… »\u003C\u002Ftd>\n\u003Ctd>« Assignés à moi », « Sprint actif », « À faire »\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Trello\u003C\u002Ftd>\n\u003Ctd>« Rechercher une carte… »\u003C\u002Ftd>\n\u003Ctd>« Mes cartes », puis une puce par liste du tableau\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>GitHub\u003C\u002Ftd>\n\u003Ctd>« Rechercher une issue… » (un numéro, \u003Ccode class=\"key\">42\u003C\u002Fcode> ou \u003Ccode class=\"key\">#42\u003C\u002Fcode>, trouve l’issue)\u003C\u002Ftd>\n\u003Ctd>« Assignées à moi », puis les étiquettes du dépôt (douze au plus)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Linear\u003C\u002Ftd>\n\u003Ctd>« Rechercher par identifiant (ENG-42) ou par titre… »\u003C\u002Ftd>\n\u003Ctd>« Mes issues », puis une puce par état du workflow qui n’est ni terminé ni annulé\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Seuls les tickets ouverts sont proposés : pas ceux de la catégorie « Done » de Jira, ni les issues fermées de GitHub (les pull requests sont laissées de côté), ni les issues terminées ou annulées de Linear.\u003C\u002Fp>\n\u003Cp>Chaque ligne montre la clé, le titre, le type (Bug, Story, Tâche, Carte, Issue), la priorité, la personne assignée et l’état, et « ✓ 2 critères détectés » (au survol : lesquels). Un ticket déjà dans le Kanban est grisé (« Déjà dans le Kanban ») et ne se choisit pas. Les tickets arrivent par pages ; « Afficher plus » charge la suivante, et la ligne au-dessus de la liste dit « 50 affichés sur 312 » quand le service compte plus de tickets qu’il n’en a envoyé.\u003C\u002Fp>\n\u003Cp>Pour importer :\u003C\u002Fp>\n\u003Col>\n\u003Cli>Coche les tickets (un clic, ou \u003Ccode class=\"key\">Espace\u003C\u002Fcode> ou \u003Ccode class=\"key\">Entrée\u003C\u002Fcode> sur une ligne), ou « Tout sélectionner » pour ceux de la liste qui ne sont pas déjà importés. La sélection se garde d’une recherche, d’une page et d’une source à l’autre.\u003C\u002Fli>\n\u003Cli>Choisis « Boucles max » (3, 5 ou 8) : le même nombre pour tous les tickets importés.\u003C\u002Fli>\n\u003Cli>Clique sur « Importer 3 tickets ».\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Chaque ticket importé a sa propre clé Escouade (\u003Ccode class=\"key\">DEM-7\u003C\u002Fcode>) et garde, sur sa carte, la pastille de son service avec sa clé chez lui (\u003Ccode class=\"key\">ATL-1294\u003C\u002Fcode>) : un clic l’ouvre dans le service. Sa description reprend celle du ticket externe, et se termine par une ligne « Ticket Jira ATL-1294 : \u003Ccode class=\"key\"><adresse>\u003C\u002Fcode> ». Un message confirme (« 3 tickets importés depuis Jira et Trello »). Avec le pilote auto allumé, les tickets importés partent d’eux-mêmes (voir \u003Ca href=\"\u002Fdocs\u002Fautopilot\u002F\">Le pilote auto\u003C\u002Fa>).\u003C\u002Fp>\n\u003Ch3 id=\"les-criteres-d-acceptation\">Les critères d’acceptation\u003C\u002Fh3>\n\u003Cp>Avec « Extraire les critères d’acceptation » activé (par défaut), Escouade cherche les critères dans le ticket :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Jira et GitHub : les éléments de liste sous un titre ou une ligne qui les nomme (« Critères d’acceptation », « Acceptance criteria », « Definition of done », « AC », « DoD »), sinon les cases à cocher (\u003Ccode>- [ ]\u003C\u002Fcode>) de la description ;\u003C\u002Fli>\n\u003Cli>Trello : les éléments de la checklist qui porte ce nom, sinon ceux de toutes les checklists, sinon ceux que la description liste ;\u003C\u002Fli>\n\u003Cli>Linear : comme pour Jira et GitHub, dans la description.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Il garde vingt critères au plus, de 300 caractères au plus. Sans critère trouvé, ou avec le réglage éteint, le ticket reçoit les deux critères par défaut. La description Jira est convertie en Markdown avant d’être cherchée.\u003C\u002Fp>\n\u003Ch2 id=\"importer-par-etiquette\">Importer par étiquette\u003C\u002Fh2>\n\u003Cp>Réglages › Intégrations › « Import automatique » laisse Escouade importer toute seule :\u003C\u002Fp>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Réglage\u003C\u002Fth>\n\u003Cth>Rôle\u003C\u002Fth>\n\u003Cth>Par défaut\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>« Importer les tickets étiquetés »\u003C\u002Ftd>\n\u003Ctd>Les tickets ouverts des sources liées qui portent l’étiquette arrivent dans « À faire »\u003C\u002Ftd>\n\u003Ctd>Éteint\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Étiquette »\u003C\u002Ftd>\n\u003Ctd>Le label Jira, l’étiquette Trello, GitHub ou Linear\u003C\u002Ftd>\n\u003Ctd>\u003Ccode class=\"key\">claude-ready\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Vérifier toutes les »\u003C\u002Ftd>\n\u003Ctd>L’intervalle entre deux passes : 5, 15 ou 60 min\u003C\u002Ftd>\n\u003Ctd>15 min\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Une passe regarde, dans chaque projet, les sources liées dont le compte est connecté. Les tickets arrivent avec 5 boucles maximum, et un message l’annonce (« 3 tickets importés depuis Jira dans demo »). Un ticket que le projet a déjà importé n’est jamais ramené, même si tu l’as supprimé du Kanban depuis. La première passe a lieu peu après l’activation.\u003C\u002Fp>\n\u003Ch2 id=\"le-statut-et-les-commentaires-suivent-le-ticket\">Le statut et les commentaires suivent le ticket\u003C\u002Fh2>\n\u003Cp>Quand un ticket importé change de colonne, Escouade met à jour le ticket externe. Les liens, la correspondance des statuts et les commentaires se règlent par projet ; les trois réglages du groupe « Synchronisation » valent pour tous les projets.\u003C\u002Fp>\n\u003Ch3 id=\"correspondance-des-statuts\">Correspondance des statuts\u003C\u002Fh3>\n\u003Cp>Le groupe « Correspondance des statuts » (une fois une source liée) a une ligne par colonne du Kanban et, pour chaque service lié, une liste de statuts. « — inchangé » laisse le ticket externe tel qu’il est. Choisir une source pré-remplit les colonnes ainsi :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>« En cours » et « À tester » : le statut qui ressemble à « en cours » (\u003Ccode>In Progress\u003C\u002Fcode>, \u003Ccode>En cours\u003C\u002Fcode>, \u003Ccode class=\"key\">Doing\u003C\u002Fcode>, \u003Ccode class=\"key\">WIP\u003C\u002Fcode>, \u003Ccode>In development\u003C\u002Fcode>, \u003Ccode class=\"key\">Started\u003C\u002Fcode>…) ;\u003C\u002Fli>\n\u003Cli>« Terminé » : le statut qui ressemble à « à tester » (\u003Ccode>To test\u003C\u002Fcode>, \u003Ccode class=\"key\">Testing\u003C\u002Fcode>, \u003Ccode class=\"key\">QA\u003C\u002Fcode>, \u003Ccode>In Review\u003C\u002Fcode>, \u003Ccode class=\"key\">Review\u003C\u002Fcode>, \u003Ccode class=\"key\">Recette\u003C\u002Fcode>, \u003Ccode>À valider\u003C\u002Fcode>, \u003Ccode class=\"key\">Validation\u003C\u002Fcode>, \u003Ccode class=\"key\">Test\u003C\u002Fcode>…) ;\u003C\u002Fli>\n\u003Cli>« À faire » : inchangé.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Ce que « statut » veut dire dépend du service : une transition de workflow pour Jira, la liste où la carte se range pour Trello, un état du workflow pour Linear. Pour GitHub, ce sont « Ouverte », « Fermée » ou une étiquette du dépôt (marquée ◆) : « Fermée » ferme l’issue, une étiquette la rouvre si besoin et retire les autres étiquettes de la correspondance.\u003C\u002Fp>\n\u003Cp>La dernière colonne, « Commenter », choisit les colonnes dont l’arrivée écrit un commentaire (par défaut « À tester » et « Terminé »). Le commentaire dit où en est le ticket :\u003C\u002Fp>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Colonne\u003C\u002Fth>\n\u003Cth>Commentaire\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>« À faire »\u003C\u002Ftd>\n\u003Ctd>« Escouade : DEM-5 est revenu « À faire ». »\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« En cours »\u003C\u002Ftd>\n\u003Ctd>« Escouade : DEM-5 est pris par un agent (branche ticket\u002Fdem-5). »\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« À tester »\u003C\u002Ftd>\n\u003Ctd>« Escouade : DEM-5 est prêt à tester. » (avec « (objectif partiel) » le cas échéant), les critères (✓ ou ○, avec la note de l’agent) et « Ce qui a été fait ».\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Terminé »\u003C\u002Ftd>\n\u003Ctd>« Escouade : DEM-5 est terminé — » suivi de l’issue (« ⤵ Mergé dans main · squash »), et du lien de la pull request s’il y en a une.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"les-reglages-de-synchronisation\">Les réglages de synchronisation\u003C\u002Fh3>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Réglage\u003C\u002Fth>\n\u003Cth>Rôle\u003C\u002Fth>\n\u003Cth>Par défaut\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>« Mettre à jour le statut externe »\u003C\u002Ftd>\n\u003Ctd>Quand un ticket importé change de colonne, son ticket externe prend le statut de la correspondance\u003C\u002Ftd>\n\u003Ctd>Activé\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Publier un résumé à chaque boucle »\u003C\u002Ftd>\n\u003Ctd>À chaque nouvelle boucle, un commentaire donne les critères atteints et les notes de l’agent (« Escouade : DEM-5, boucle 2\u002F5 — 1\u002F3 critères atteints. »)\u003C\u002Ftd>\n\u003Ctd>Éteint\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Extraire les critères d’acceptation »\u003C\u002Ftd>\n\u003Ctd>Voir plus haut\u003C\u002Ftd>\n\u003Ctd>Activé\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"la-langue-des-commentaires\">La langue des commentaires\u003C\u002Fh3>\n\u003Cp>Les commentaires sont publiés pour ton équipe : ils sont écrits dans la « Langue des textes rédigés par Claude » (Réglages › Application, voir \u003Ca href=\"\u002Fdocs\u002Fsettings-application\u002F\">Réglages de l’application\u003C\u002Fa>), pas dans celle de l’interface. L’issue d’un ticket terminé y est citée dans cette même langue.\u003C\u002Fp>\n\u003Ch2 id=\"synchronisations-qui-echouent\">Synchronisations qui échouent\u003C\u002Fh2>\n\u003Cp>Chaque changement à répercuter est gardé dans une file, \u003Ccode>~\u002F.escouade\u002Fsync-queue.json\u003C\u002Fcode>, jusqu’à ce que le service l’ait pris. Les changements d’un ticket partent dans l’ordre, l’un après l’autre : un changement qui échoue retient les suivants du même ticket, pas ceux des autres tickets. Une transition de statut remplace celle qui n’est pas encore partie pour le même ticket, et un ticket qui revient dans une colonne précédente annule la transition qui n’était pas partie.\u003C\u002Fp>\n\u003Cp>Une carte dont la synchronisation a échoué affiche un ⚠. Un clic dessus montre la raison (« Jira refuse ces identifiants (401) », « Jira : aucune transition de « En cours » vers « Done » pour ATL-1294 »…) et le bouton « Resynchroniser ».\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Quand le service est injoignable, en panne ou trop sollicité, ou qu’il refuse les identifiants (ce qui se répare), l’échec peut passer plus tard : Escouade réessaie seule, après 1, 5, 15 puis 60 minutes, la dernière attente étant répétée, pendant 24 heures à partir du premier échec.\u003C\u002Fli>\n\u003Cli>Un refus qu’un nouvel essai ne changerait pas (requête refusée telle quelle, ticket disparu, aucune transition vers le statut) est mis de côté tout de suite, comme tout ce qui échoue encore au bout d’un jour. Il ne retient plus les changements suivants du ticket.\u003C\u002Fli>\n\u003Cli>Au démarrage d’Escouade, tout ce qui attendait repart (sauf ce qui a été mis de côté).\u003C\u002Fli>\n\u003Cli>« Resynchroniser » renvoie tout de suite, mis de côté compris. Quand il ne reste rien à envoyer, il redonne au ticket externe le statut de sa colonne (sans réécrire de commentaire). Le ⚠ disparaît dès que tout est passé.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Supprimer le ticket du Kanban abandonne ce qui attendait pour lui.\u003C\u002Fp>\n\u003Ch2 id=\"voir-aussi\">Voir aussi\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fboard\u002F\">Le Kanban\u003C\u002Fa> : la carte d’un ticket importé.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fsettings-integrations\u002F\">Réglages des intégrations\u003C\u002Fa> : la liste complète des réglages.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fmcp\u002F\">Le serveur MCP\u003C\u002Fa> : le ticket externe d’un ticket se lit avec \u003Ccode class=\"key\">get_ticket\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n",[8,12,16,19,22,25,28,31,34,37,40,43],{"id":9,"text":10,"depth":11},"connecter-un-service","Connecter un service",2,{"id":13,"text":14,"depth":15},"ou-sont-gardes-les-jetons","Où sont gardés les jetons",3,{"id":17,"text":18,"depth":11},"lier-un-projet-a-une-source","Lier un projet à une source",{"id":20,"text":21,"depth":11},"importer-des-tickets","Importer des tickets",{"id":23,"text":24,"depth":15},"les-criteres-d-acceptation","Les critères d’acceptation",{"id":26,"text":27,"depth":11},"importer-par-etiquette","Importer par étiquette",{"id":29,"text":30,"depth":11},"le-statut-et-les-commentaires-suivent-le-ticket","Le statut et les commentaires suivent le ticket",{"id":32,"text":33,"depth":15},"correspondance-des-statuts","Correspondance des statuts",{"id":35,"text":36,"depth":15},"les-reglages-de-synchronisation","Les réglages de synchronisation",{"id":38,"text":39,"depth":15},"la-langue-des-commentaires","La langue des commentaires",{"id":41,"text":42,"depth":11},"synchronisations-qui-echouent","Synchronisations qui échouent",{"id":44,"text":45,"depth":11},"voir-aussi","Voir aussi",1791926754947]