Tribune : la transformation de la TMA en outsourcing applicatif

La notion de TMA traditionnelle repose sur trois activités : la maintenance applicative, le support et les améliorations. On est donc bien dans une logique d’infogérance, c’est-à-dire de « run ». Or, au contraire, les nouveaux contrats de TMA intègrent de plus en plus la notion de projet de type développement ou intégration. La différence entre « build » et « run » tend à s'atténuer pour plusieurs raisons :

1) Dans le cadre d'applicatifs spécifiques, la différence est parfois artificielle. Certains logiciels demandent des évolutions en permanence qui, sans être des projets nouveaux, correspondent à un changement important des fonctionnalités. On citera pour exemple les logiciels sensibles à des changements réglementaires, notamment dans les services financiers.

2) Les donneurs d'ordre ont largement eu recours à la massification de leurs contrats de TMA. Ils ont pris l’habitude de regrouper leurs contrats existant et d'en confier la responsabilité à un nombre limité de prestataires. La logique de ces contrats est de d’obtenir des rabais en augmentant le périmètre des projets, donc les volumes. A ce titre, il est particulièrement tentant pour un client d'inclure dans son contrat de TMA un volet d'intégration qui lui permet de réduire les prix et de disposer d’équipes à l'avance. Dans le même ordre idée, l'approche adoptée par une banque néerlandaise en 2005, ABN AMRO,  semble avoir fait des émules : la société avait confié sa TMA à trois SSII (indiennes en l'occurrence) et attribué un titre de « partenaire privilégié » à cinq SSII pour les projets d'intégration. Le responsable informatique avait confié à l'époque que les SSII en charge de la maintenance auraient nécessairement plus facilement accès aux projets d'intégration, au moins à ceux touchant le périmètre applicatif qui leur est confié. 

3) L’émergence de l’offshore indien en France fait apparaître une notion un peu nouvelle : celle de l’ADM (pour « application development and maintenance »). La encore, la différence entre « améliorations » et « développement » devient ténue ; historiquement, les Indiens intervenaient aux Etats-Unis sur un mode assistance technique sur site client et ne possédaient pas la responsabilité du contrat. Peu importe alors si les employés des SSII indiennes travaillaient sur un nouveau développement ou sur une maintenance préventive !

Des risques accrus à gérer

Si, traditionnellement, on externalise la maintenance et on conserve l’intégration en interne (ou on la confie à un prestataire en mode projet), c’est bien sûr pour garder un contrôle sur les activités de « build », c’est-à-dire sur des activités de transformation par nature plus risquées – en théorie – que celles de « run », de gestion de l’existant. Cette séparation avait aussi un volet humain essentiel : celui de décharger les équipes internes des tâches les moins intéressantes pour se concentrer sur le développement.

Bref, le mélange des deux genres peut prêter à confusion d’autant que des anciennes pratiques redeviennent plus populaires, notamment celles de contrats d’outsourcing applicatif impliquant le transfert de personnel. Ce genre de contrats focalisés sur l’applicatif sont peu courants en France, mais bien plus fréquents au Royaume-Uni. Outre les risques de perte de connaissance du patrimoine applicatif, ces contrats présentent d’autres dangers dont des questions plus stratégiques, comme celle de portant sur l’importance des applications pour une entreprise. Les logiciels ont-ils vocation à être externalisés de la même manière que certaines fonctions support comme la restauration d’entreprise ?

D’une manière plus immédiate, le transfert de départements entiers implique une réorganisation en profondeur des directions informatiques pour faire évoluer l'activité opérationnelle quotidienne vers une expertise de gestion des prestataires, de respect des contrats et de développement d’une stratégie informatique en termes technologiques, d’architecture et de choix structurants (progiciels ou logiciels à façon par exemple). En outre, ces contrats font un usage grandissant de l’offshore. C’est dire s'ils risquent de provoquer de multiples dérapages en termes d’exécution. 

Bref, sur un marché français qui ne sort que graduellement de l’assistance technique, il s’agit d’une vraie révolution. Le bon sens suggère donc de ne pas brûler les étapes, surtout que lesdites étapes intermédiaires sont nécessaires. Pour une bonne partie des donneurs d’ordre, la première d'entre elles consiste à évoluer du mode assistance technique au mode forfait ou développement en usine logiciel. La remarque est sans doute triviale. Mais, à bien analyser  les chiffres de nos SSII nationales, une majorité des effectifs des prestataires français en intégration de systèmes restent localisés sur site. La montée en puissance des effectifs hors site est importante, mais ils demeurent une minorité. Sopra, une SSII qu'on peut considérer en France comme l’une des plus industrialisées sur les services applicatifs, donne un benchmark intéressant : 25 % seulement des effectifs français de la SSII sont situés dans des usines logicielles en France ou à l’étranger (Inde, Maroc et Espagne).

Est-ce-à-dire qu’il faut refuser les nouvelles pratiques d’intégration et de maintenance ? Certainement non. Elles sont porteuses d’améliorations sensibles en matière de qualité des logiciels, d'organisation des directions informatiques et de dépenses opérationnelles. Néanmoins, ces nouvelles pratiques comportent de nouvelles formes de risques dont tous les donneurs d’ordre n’ont pas encore mesuré toute l’étendue… Pas plus que les prestataires eux-mêmes.

En savoir plus : lire notre enquête sur la gestion du patrimoine applicatif