Nous pouvons cadrer, configurer, prendre en main, intégrer et migrer nos propres add-ons. Nous ne conseillons pas sur l’écosystème Atlassian et nous n’implémentons, n’intégrons, ne migrons, n’administrons ni ne configurons Jira, Confluence ou tout autre produit Atlassian.
Si un prérequis se situe hors de cette frontière, votre administrateur Atlassian ou votre spécialiste reste responsable de sa réalisation.
Chaque parcours commence par une app addly nommée et se termine par une preuve d’acceptation propre à cette app. Le périmètre exact, la disponibilité, le calendrier et les conditions commerciales doivent être confirmés par écrit avant tout démarrage.
Traduire le cas d’usage visé en surfaces, réglages, données propres à l’app, dépendances et seuils d’arrêt explicites.
Un scénario d’app délimité et testable.
Inscrire l’app addly dans le flux client convenu et ne relier que les entrées et sorties propres à l’app couvertes par ses capacités documentées.
L’app rejoint un moment réel de travail sans refondre l’environnement Atlassian.
Préparer et appliquer les réglages, règles, correspondances et rôles internes qui appartiennent à l’add-on addly.
Une configuration d’app reliée à un registre approuvé.
Guider les personnes qui administreront ou utiliseront l’app addly à travers son scénario principal, ses limites et son parcours de diagnostic.
Une équipe capable d’exploiter l’app dans le cas d’usage convenu.
Inventorier, répéter, transférer, rapprocher et, lorsque la technique le permet, restaurer uniquement les données et configurations appartenant à l’app addly.
Une migration d’app maîtrisée, avec contrôles et limites consignés.
Un brief utile décrit l’app, le moment de travail visé et les conditions permettant au client de la tester en sécurité. Il ne demande pas à addly d’auditer tout le patrimoine Atlassian.
Le client décide et réalise toute modification nécessaire de Jira, Confluence, l’identité, le réseau, les achats ou un produit tiers qui se situe hors de l’app addly.
La matrice de responsabilités empêche qu’un accompagnement d’app s’étende silencieusement à l’administration ou à la transformation des produits hôtes.
| Étape | addly | Client | Gate de sortie |
|---|---|---|---|
| Cadrer | Décrire la frontière de l’app addly, son scénario, les hypothèses et les preuves nécessaires. | Confirmer le scénario métier, le responsable, le contexte hôte et les prérequis externes. | Le périmètre écrit nomme ce qui est inclus et exclu. |
| Préparer | Proposer les réglages de l’app, le traitement de ses données, les tests et les conditions de retour arrière propres à l’app. | Fournir les accès autorisés, données de test, approbations et éventuelle configuration du produit hôte. | Les entrées et seuils d’arrêt sont complets. |
| Configurer | Appliquer ou guider uniquement les réglages et connexions convenus à l’intérieur de l’app addly. | Administrer Jira, Confluence, les identités, les réseaux et les produits tiers. | La configuration correspond au registre approuvé. |
| Valider | Démontrer le comportement attendu de l’app, consigner ses défauts et rapprocher ses données lorsque nécessaire. | Réaliser la recette métier et confirmer la gouvernance de l’organisation, de la sécurité et du produit hôte. | Preuves, exceptions et responsabilités sont consignées. |
| Transmettre | Fournir les éléments propres à l’app qui ont été confirmés et ses limites connues. | Approuver le changement en production, conserver les pièces et assumer l’administration continue du produit hôte. | L’app possède un responsable et une prochaine action explicite. |
Ces modèles décrivent des résultats utiles. Ils ne constituent ni un forfait publié, ni un droit inclus, ni un engagement de disponibilité, de date de livraison ou de niveau de service.
Cas d’usage, frontière de l’app, hypothèses, prérequis, exclusions, responsables et seuils d’arrêt.
Réglages, règles, correspondances, justification et état de validation convenus pour l’app.
Scénario de test, comportement attendu de l’app, résultat observé, exceptions et prochaine décision.
Parcours propre à l’app, notes d’administration, limites connues et voie de diagnostic du support.
Inventaire, répétition, bascule, rapprochement, seuils d’arrêt et retour arrière pour les seules données addly éligibles.
Avant le démarrage, un brief écrit doit confirmer les éléments réellement fournis, leur format, leur responsable et la preuve nécessaire à leur acceptation.
Un accompagnement doit se conclure par des preuves, et non par une affirmation vague selon laquelle la configuration serait terminée.
Ces exclusions font partie de l’offre ; elles ne sont pas reléguées en petites lignes. addly assume la description de sa propre app et refuse de laisser entendre une activité de services professionnels plus large.
Si une réponse conduisait l’accompagnement au-delà de l’app addly, le travail reste sous la responsabilité du client ou de son spécialiste.
Non. addly conçoit et vend ses propres add-ons. Tout accompagnement d’implémentation, d’intégration, de configuration, d’onboarding ou de migration se limite à ces add-ons.
Non. addly peut préciser le prérequis et configurer sa propre app. L’administrateur du client ou le prestataire choisi modifie Jira, Confluence, les identités, les réseaux et les autres produits.
Non. Une migration ne peut couvrir que les données et configurations éligibles appartenant à une app addly. Les contenus du produit hôte, projets, espaces, utilisateurs et données d’apps tierces restent exclus.
Pas au regard des preuves actuellement publiées. La page fournit des modèles de périmètre et de livrables ; disponibilité opérationnelle, conditions, prix, calendrier et résultats inclus doivent être confirmés par écrit.
Le brief consigne le prérequis, son responsable et la preuve d’acceptation. addly peut valider l’app une fois ce prérequis présent, mais le client reste responsable du travail hors de la frontière de l’app.
Préparez un brief pour une app addly et un scénario observable. Le brief reste copiable localement même si l’envoi conforme n’est pas activé.