Résumé

  • Atlassian annonce 46 Forward Deployed Engineers, plus de 100 entreprises accompagnées et plus de 80 agents IA en production, avec une équipe appelée à approcher 100 personnes. Ces instantanés déclaratifs ne forment pas une cohorte de productivité comparable.
  • Le programme place des ingénieurs au contact des flux de travail des clients et suit quatre étapes sur environ douze semaines : découverte, construction, adoption et mesure de la valeur. Les exemples publiés par Atlassian sont intéressants, mais anonymes et non vérifiés indépendamment.
  • La question commerciale est de savoir si chaque mission laisse un produit réutilisable et une exploitation autonome côté client, ou si le déploiement, la gouvernance et le support continuent de dépendre d’une main-d’œuvre rare. Aucun tarif, marge ou revenu récurrent propre au programme n’est publié.

Quarante-six ingénieurs, plus de cent entreprises, plus de quatre-vingts agents IA en production : Atlassian présente ainsi son programme de Forward Deployed Engineering (FDE). L’entreprise dit faire évoluer l’équipe vers cent personnes. Mais ces volumes ne répondent pas à la question décisive : combien de temps chaque client mobilise-t-il, combien de temps dure la mission et que reste-t-il quand les ingénieurs s’en vont ? (Entretien publié le 7 octobre)

L’ingénierie déployée chez le client n’est pas une invention d’Atlassian. Le principe consiste à rapprocher les techniciens du travail réel, des données et des systèmes afin de transformer un besoin mal défini en solution installée. Chez Atlassian, le programme est orienté vers l’IA : les ingénieurs co-conçoivent des agents Rovo ou des automatisations, relient des systèmes et reconfigurent des processus. La page du programme présente quatre phases — découvrir, construire, adopter et mesurer la valeur — sur environ douze semaines. (Programme FDE d’Atlassian)

Cette méthode vise un obstacle concret. Un modèle peut fonctionner techniquement sans être exploitable dans une entreprise où les connaissances sont dispersées, les permissions incertaines, les transmissions fragiles et la responsabilité du changement mal attribuée. Un ingénieur intégré peut cartographier le travail réel, délimiter un cas d’usage, relier les systèmes nécessaires et intégrer la sécurité dès la conception plutôt que lors d’un contrôle tardif. Ce n’est pas la même vente qu’une licence dont l’adoption est ensuite laissée au client.

La structure de coûts change elle aussi. Un logiciel en abonnement peut servir un client supplémentaire à faible coût marginal si les processus, les intégrations et le support sont standardisés. Une mission FDE part du contexte propre au client et vise une mise en production. Si l’essentiel du travail est spécifique, la croissance dépend du recrutement, de la capacité de déploiement et du temps des ingénieurs expérimentés. Si les enseignements deviennent des fonctionnalités, connecteurs, règles de permission ou guides réutilisables dans Rovo et Teamwork Graph, chaque mission peut améliorer le produit et alléger la suivante.

Les chiffres publiés ne permettent pas de départager ces effets. Les 100 entreprises et les 80 agents ne sont pas définis comme une même cohorte ; le nombre d’agents maintenus par client et leur activité après le lancement restent inconnus. On ne peut pas diviser le nombre d’ingénieurs par celui des clients ou des agents pour produire un indicateur de rendement : les dates, périmètres et étapes des mesures peuvent différer. Atlassian ne publie pas les tarifs, heures facturables, revenus, contribution par projet ni charge de support après lancement.

La page commerciale évoque plus de 20 millions de dollars d’économies pour une entreprise technologique, environ 50 % d’effort de triage en moins chez un fabricant de semi-conducteurs et plus de 6 700 heures annuelles économisées pour une entreprise de voyage. Ces cas éclairent la proposition de valeur, mais ils sont anonymisés et publiés par Atlassian. Les bases de comparaison, méthodes, coûts d’engagement, périodes de mesure et validations indépendantes ne sont pas présentés. Ils ne constituent donc ni un rendement représentatif ni la preuve que les économies profitent à Atlassian. (Résultats présentés par Atlassian)

L’enjeu est celui de l’effet de levier logiciel. Au quatrième trimestre de l’exercice 2026, Atlassian a déclaré 1,766 milliard de dollars de chiffre d’affaires, sans ligne distincte pour les revenus ou coûts de FDE. La croissance consolidée du cloud ne peut être attribuée aux ingénieurs intégrés sans données de cohorte ou contrats. Le programme peut favoriser l’expansion, la fidélisation et l’apprentissage produit ; il peut aussi rester un service client coûteux noyé dans les charges plus larges. Les comptes publiés ne répartissent pas ces effets. (Résultats FY2026 ; Form 10-K FY2026)

La conclusion la plus prudente n’est ni « du conseil déguisé en logiciel », ni « l’adoption de l’IA est réglée ». Le programme sert d’interface entre l’intention d’une entreprise et l’usage du produit. Sa valeur dépend de ce qui subsiste après le projet : une fonction réutilisable, une intégration répétable, un schéma de permission sûr ou une équipe cliente capable d’opérer seule. Les douze semaines décrivent un modèle, pas la durée vérifiée de chaque mission ni l’autonomie de chaque client.

Cette autonomie devient donc un test produit. Si l’agent ne fonctionne qu’avec l’équipe initiale pour surveiller les exceptions, entretenir les intégrations et modifier les permissions, le statut « en production » peut cacher une obligation de service durable. Si le client sait exploiter, auditer et ajuster l’agent avec les outils ordinaires de la plateforme, le même projet peut devenir un modèle reproductible. La question n’est pas de savoir si des ingénieurs entrent chez le client, mais ce qu’ils y laissent.

La prochaine preuve utile devrait relier volumes et cohortes : durée des missions, part menée jusqu’à la production, persistance à six ou douze mois, support post-lancement, expansion et fonctionnalités réutilisées. Atlassian montre l’effort de déploiement et une voie plausible d’apprentissage produit. Il ne montre pas encore quelle part de cet effort se compose comme du logiciel plutôt que de se répéter sous forme de travail humain.

Sources