Lorsque les entreprises intègrent l’IA dans leurs flux de travail existants, il faut toujours des personnes responsables du déploiement, de la maintenance et du transfert. Le modèle FDE publié par Atlassian offre un exemple organisationnel étudiable pour ces responsabilités. Cet article le présente comme référence de livraison pour les équipes d’ingénierie post‑investissement en capital‑investissement ; l’événement ne concerne pas une opération de prise de participation.
Fait : projet de 12 semaines livré conjointement avec les ingénieurs du client
- 7 octobre 2026 , Atlassian a annoncé le plan FDE : les ingénieurs interviennent dans l’environnement du client, la période de collaboration typique étant de 12 semaines, le client mobilisant également ses propres ingénieurs. Le service comprend un agent Rovo personnalisé, la connexion de systèmes et l’automatisation des flux de travail.
- L’entreprise a indiqué que le projet Expedia a archivé 600 000 pages de contenu Confluence, permettant d’économiser environ 3,200 heures par an ; il s’agit d’une donnée de divulgation de l’entreprise, pas encore vérifiée par un audit financier.
- Le même jour, le blog officiel a révélé que l’équipe compte déjà 46 ingénieurs, a servi plus de 100 entreprises clientes, et que plus de 80 agents IA sont en production. L’entreprise affirme que le code, les connecteurs et les améliorations produits issus du site seront réintégrés dans le système de produits.
Conclusion : les équipes post‑investissement devraient inclure la capacité de transfert dans les critères d’acceptation
Selon l’évaluation FDEPE, le principal enseignement de ce modèle est d’intégrer le personnel du client dans le processus de construction. Pour les équipes de transformation des sociétés contrôlées, la fin du projet doit inclure à la fois la disponibilité opérationnelle et la prise en charge organisationnelle : le responsable métier doit pouvoir expliquer les résultats, les ingénieurs internes doivent pouvoir maintenir les connecteurs, et en cas d’anomalie, quelqu’un doit pouvoir désactiver les actions automatisées et rétablir le processus manuel. Sinon, une fois l’équipe sur site partie, le déploiement à court terme risque de se transformer en dépendance d’externalisation à long terme.
Il est recommandé de diviser un projet en trois questions d'acceptation. Premièrement, le processus est-il réellement remplacé : enregistrer le volume total des tâches, le taux d'intervention humaine, le taux de retouche et le temps de traitement, afin d'éviter de ne compter que le nombre d'appels. Deuxièmement, l'amélioration couvre-t-elle l'intégralité des coûts : inclure les ingénieurs internes, les équipes sur site externes, les appels de modèle, la révision et la maintenance dans le coût du projet. Troisièmement, le client peut-il fonctionner de façon autonome : faire réaliser par l'équipe du client une mise à jour de version et une récupération après incident, afin de vérifier si la documentation de transfert est suffisante. Ce sont les méthodes d'évaluation proposées dans cet article, qui ne reflètent pas nécessairement l'adoption de ces indicateurs par Atlassian.
Les économies d'heures de travail doivent encore être converties financièrement. Si les employés utilisent le temps libéré pour traiter davantage d'arriérés, tandis que les salaires et les dépenses d'externalisation restent inchangés, les bénéfices se manifestent d'abord sous forme de capacité et de qualité de service. Ce n'est qu'après avoir lié ces économies à des revenus supplémentaires, à la suppression de l'externalisation, à la réduction des heures supplémentaires ou à l'évitement de recrutements que l'on peut les intégrer dans le calcul de l'amélioration du profit. Il ne faut pas multiplier toutes les heures économisées par le salaire et les considérer comme un gain de trésorerie réalisé.
La réutilisation de la plateforme doit également faire l'objet d'une acceptation distincte. Lorsqu'un client suivant utilise la même capacité, s'il faut encore nettoyer les données, réécrire les autorisations et refaire les approbations de processus, le coût de livraison peut ne pas diminuer de façon notable. L'équipe d'ingénierie post‑investissement peut suivre le nombre de jours‑homme du deuxième déploiement, le pourcentage de composants réutilisables directement et les heures de maintenance du client, afin de déterminer si l'expérience se transforme en un actif réplicable.
Preuve contraire : le nombre de déploiements en production n'est pas égal au profit réplicable.
- Les documents publics ne divulguent pas les frais par projet, le coût complet des ingénieurs, les groupes de contrôle ou les gains de trésorerie, ce qui empêche de calculer le retour net du projet à partir de ces informations.
- Les résultats de gouvernance de contenu d'un client unique ne peuvent pas être automatiquement extrapolés aux processus d'achat, de gestion des risques ou d'approbation financière ; chaque type de tâche a des coûts d'erreur et des limites d'autorisation différents.
- La réutilisation au sein de l'écosystème produit du fournisseur ne peut pas être directement transférée aux systèmes hétérogènes d'une société du portefeuille. Si le client co‑construit en mobilisant beaucoup de talents internes, la vitesse du projet peut également être compromise au profit de retards dans d'autres travaux.
Annonce d'Atlassian, 7 octobre 2026, publiée par Business Wire (republication intégrale par Finviz).
Blog officiel d'Atlassian : Meet the Forward Deployed Engineer, 7 octobre 2026.