Développer une app Forge ou Marketplace : la responsabilité d'éditeur que vous endossez

Tant que vous intervenez en mission, votre responsabilité est circonscrite : une erreur de paramétrage touche un client, un préjudice, un dossier. Le jour où vous publiez une app — sur la plateforme Forge d'Atlassian ou en distribution Marketplace — la logique bascule. Vous n'êtes plus seulement consultant : vous devenez éditeur de logiciel, et votre code tourne simultanément chez tous ceux qui l'ont installé.

Ce changement de nature est rarement anticipé. Un consultant développe une petite app Forge pour automatiser un workflow Jira, la publie en libre accès, et se retrouve quelques mois plus tard avec des centaines voire des milliers d'installations actives. À ce stade, un seul bug se propage à tout le parc : une mise à jour qui casse un automatisme, un calcul erroné qui corrompt des données dans chaque instance, une régression qui bloque un type de transition Jira partout en même temps.

L'exposition n'est plus proportionnelle à une mission, elle l'est au nombre d'utilisateurs. C'est exactement le profil de risque d'un éditeur, et il appelle une couverture pensée pour cela — pas la simple RC Pro de prestation de services calibrée pour un client à la fois.

Publier une app concentre des risques que la mission ne connaît pas :

• Le bug de masse. Une version contenant une régression est poussée automatiquement à toutes les installations. Si l'app manipule des données (champs personnalisés, automatisations, reporting), l'erreur peut corrompre ou supprimer du contenu chez chaque utilisateur simultanément. Le préjudice cumulé dépasse vite tout ce qu'une mission isolée pourrait générer.
• La faille de sécurité. Une app Forge a des permissions sur l'instance qui l'héberge. Une vulnérabilité — injection, mauvaise gestion d'un token, fuite de données entre clients — peut transformer votre app en vecteur d'incident pour l'ensemble de votre base installée, avec une dimension cyber évidente.
• La dépendance et la rupture de service. Si votre app dépend d'un service tiers, d'une API externe ou d'un quota, une défaillance peut interrompre une fonction critique chez tous vos clients. L'indisponibilité d'une app de release management, par exemple, paralyse les déploiements de chaque équipe qui en dépend.

Atlassian impose d'ailleurs des exigences de sécurité aux apps Marketplace, en particulier pour celles intégrées au programme de sécurité de l'éditeur. Ces obligations renforcent la présomption de professionnalisme attendue de vous : un défaut de sécurité dans votre app est plus difficilement excusable.

Un contrat RC Pro standard est dimensionné pour une activité de conseil et de paramétrage. Il prévoit des plafonds et des modalités pensés pour des sinistres unitaires. L'activité d'édition de logiciel distribué change deux paramètres essentiels :

1. Le plafond. Un sinistre qui touche des centaines d'installations peut additionner des préjudices bien au-delà du plafond d'une RC Pro de mission. La distribution d'une app publique nécessite généralement un plafond renforcé, adapté au volume potentiel de réclamations.
2. La déclaration d'activité. L'assureur couvre l'activité que vous avez déclarée. Si vous avez souscrit comme "consultant" et que vous publiez des apps sans le mentionner, l'édition peut être considérée comme une activité non déclarée — donc non couverte. La déclaration explicite du développement et de la distribution d'apps est impérative.

La règle est simple : déclarez précisément ce que vous faites. Un consultant qui combine missions et édition d'apps doit le dire à la souscription pour que le contrat embrasse les deux activités, avec un plafond cohérent avec le risque d'édition. C'est la condition pour que la garantie joue le jour du sinistre de masse.

Une activité non déclarée n'est pas une activité moins couverte : c'est une activité potentiellement exclue. La transparence à la souscription est le premier acte de gestion du risque.

Quand on parle assurance pour un développeur d'app, on pense d'abord à la responsabilité. Mais l'éditeur indépendant a aussi un actif physique et logique critique : son poste de travail et son environnement de développement. Un consultant Atlassian qui publie des apps travaille sur une machine puissante, avec des accès privilégiés, des clés de signature, des environnements de build et de déploiement.

La perte ou la panne de ce poste a un impact direct sur votre capacité à corriger un bug en urgence ou à publier une mise à jour de sécurité. Une assurance matériel informatique couvre le vol, la casse et l'oxydation de votre équipement professionnel, où que vous travailliez — au bureau, en déplacement chez un client, en coworking. Pour un freelance dont l'outil de travail est aussi l'outil de maintenance de ses apps en production, une indisponibilité matérielle prolongée est un risque opérationnel réel.

À cela s'ajoute la dimension cyber de votre propre chaîne : si vos accès Marketplace, vos tokens de publication ou votre environnement de build sont compromis, c'est la chaîne de distribution de toutes vos apps qui est en jeu. Sécuriser et assurer cet écosystème — matériel, accès, build — fait partie d'une couverture cohérente pour qui distribue du logiciel.

L'activité d'édition d'apps Atlassian n'appelle pas une assurance unique mais un assemblage cohérent, calibré sur les trois faces du risque :

La cohérence vient de la déclaration : un consultant qui annonce clairement qu'il développe et distribue des apps obtient une RC Pro dont le plafond et le périmètre collent à l'édition, et peut y adosser les garanties complémentaires. À l'inverse, empiler des contrats sans déclarer l'édition laisse un angle mort exactement là où le risque est le plus fort.

Pour cadrer la couverture adaptée à votre profil — mission seule, édition seule, ou les deux — partez de la page métier dédiée Consultant Atlassian et déclarez précisément la part d'édition dans votre activité. C'est ce niveau de détail qui transforme une police générique en protection réellement utile le jour d'un sinistre de masse.