Autonomy-first transformation : la catégorie qui manquait

Le chiffre le plus cité du secteur — « 70 % des transformations échouent » — n'a aucune base empirique valide. Mark Hughes a remonté en 2011 aux cinq publications fondatrices : aucune preuve fiable. Le mythe arrange tout le monde : il vend de l'accompagnement.

Notre thèse, réfutable : le problème n'est pas le chiffre, c'est la métrique. Les études sérieuses mesurent budget, délais, périmètre — aucune ne mesure ce que le client sait faire seul quand le prestataire est parti. Tant que cette métrique manque, le marché récompense la dépendance. La catégorie manquante est celle dont le critère de succès est l'autonomie du client : l'autonomy-first transformation.

Les données solides, elles, sont sévères. Sur 1 471 projets IT (Flyvbjerg & Budzier, 2011), le dépassement moyen est de 27 % ; un sur six devient un « cygne noir » : +200 % de coût, près de 70 % de retard. La base de 16 000+ grands projets (Flyvbjerg, 2023) est plus nette encore :

Trois colonnes — budget, délais, bénéfices — et toujours aucune qui mesure la capacité de vos équipes après le départ du prestataire.

Le premier modèle du marché vend la recommandation : diagnostic solide, exécution à votre charge — vous restez seul quand la difficulté commence. Le second vend l'exécution comme rente : chaque évolution repasse par le prestataire, sans intérêt structurel à ce que vous appreniez.

Mazzucato et Collington (UCL, 2023) montrent que le recours massif au conseil externe capture la boucle d'apprentissage : le client cesse d'apprendre. Le National Audit Office britannique l'a chiffré en 2025 : un État dépensant 14 milliards de livres par an en numérique n'aligne que 15 personnes face à ses 19 plus gros fournisseurs. L'asymétrie de compétences n'est pas un effet secondaire : c'est le mécanisme de la dépendance.

L'autonomy-first transformation se définit contre ces deux modèles : à la fin du contrat, vos équipes exploitent, modifient et étendent le système sans nous.

Cette pratique a un nom : the Ownward Method. Cinq principes vérifiables dans un contrat, qui prolongent notre façon de construire.

Chez nous : 17 extensions Airtable en un an, dont un CRM complet, adoptées immédiatement parce que l'équipe restait dans son outil ; un moteur de synchronisation reliant six CRM/ERP par configuration lisible — une nouvelle source est un mapping, pas du code (données internes Ownward, 2026). La Suisse applique déjà le deuxième principe à son État : depuis 2024, l'art. 9 LMETA impose de publier le code source des logiciels développés pour l'administration.

Le Data Act européen s'applique depuis le 12 septembre 2025 : interfaces ouvertes, exports standard, suppression totale des frais de changement de fournisseur cloud — egress compris — au 12 janvier 2027. Concevoir réversible, c'est anticiper la norme ; les cinq formes du vendor lock-in donnent la grille de lecture.

L'exposition grandit : 52,7 % des entreprises de l'UE utilisaient du cloud payant en 2025, contre 17,8 % en 2014 (Eurostat). Dès 2016, 71 % des entreprises interrogées citaient le lock-in comme frein à l'adoption du cloud (Opara-Martins et al.).

Côté compétences, l'arithmétique est têtue : 39 % des compétences clés changeront d'ici 2030 selon les employeurs (WEF, 2025) ; la Suisse prévoit 54 400 spécialistes ICT manquants d'ici 2033 (ICT-Formation professionnelle Suisse, 2025). Impossible d'embaucher votre autonomie : chaque projet doit la transférer à vos équipes. C'est cela, la transformation autonomie.

Ce que ça coûte de ne rien faire — Un projet IT sur six finit en cygne noir : +200 % de coût moyen et près de 70 % de retard (Flyvbjerg & Budzier, 1 471 projets, 2011). L'audit public britannique de 2025 chiffre cinq programmes numériques à 3,29 milliards de livres de surcoûts et 29 années de retard cumulées. Et chaque année de dépendance aggrave l'asymétrie : moins vos équipes apprennent, plus la sortie coûte cher.

À poser en avant-vente : elles jaugent des modèles économiques, pas des personnes.

Une majorité à droite ne garantit rien ; à gauche, elle dit ce que vous achetez.

L'autonomy-first n'est pas toujours le bon achat. Pour une capacité que vous ne voulez pas internaliser — paie, infrastructure très spécialisée — la délégation durable est rationnelle. Le transfert a un coût : il mobilise vos équipes pendant le projet, et ce temps se budgète. L'autonomie ne se décrète pas non plus côté prestataire : sans interlocuteur interne qui veut apprendre, les meilleurs mécanismes échouent (Goyette et al., 2015). Enfin, nos exemples sont des données internes, pas une étude indépendante : ils illustrent la méthode sans la prouver.