La TMA est plus complexe que la seule externalisation des services de production. Les objectifs classiquement mis en avant lors de la mise en place de TMA sont la maîtrise des coûts, l’amélioration de la qualité des maintenances, l’adaptation des moyens à la variation de charge et une gestion simplifiée des ressources internes qui seront affectées aux projets innovants. Ce type de contrat satisfait à la fois le fournisseur, la DSI, les achats et les utilisateurs. Les engagements portent sur la rapidité des corrections urgentes, le nombre de défauts constatés après mise en production rapportés à la taille de la maintenance. Les prix prennent en compte la complexité des logiciels concernés et une mesure de la taille des évolutions apportées.
Lorsque la modification relève d’une intervention quasiment récurrente, un coût forfaitaire est parfois défini à travers un catalogue des maintenances fréquentes. À l’opposé, le prix d’interventions complexes est largement négocié. Les contrats mettent en avant un ensemble de procédures (appelé « plan qualité ») pour organiser ces échanges et mesurer les performances du sous-traitant.
Une source significative d’amélioration réside dans la formalisation de la gestion des évolutions qu’amène la nouvelle organisation. Par exemple, le portefeuille des demandes de maintenance est beaucoup mieux géré, car les changements demandés sont les unités d’œuvre du contrat. La gestion du coût annuel de chaque application devient une activité principale du suivi du contrat de sous-traitance. L’externalisation impose en fait une clarification du rôle des différents acteurs, une formalisation des étapes de traitement des demandes de modification, et la gestion explicite de leur coût.
En définitive, une part significative de l’amélioration globale de la prise en compte des maintenances est due à la mise en place de procédures. Les TMA, tout comme l’externalisation des productions, initient un « changement culturel », puisque le contrôle des activités menées au sein de chaque équipe de développement, jusque-là assez informel et hiérarchique, évolue vers un fonctionnement plus procédural.
Les gains associés à cette transformation sont patents lorsque la mise en place de la TMA consiste à transformer en un contrat unique les différents contrats d’une dizaine de collaborateurs d’une même SSII travaillant jusque-là « en régie ». Bien que la mise en place des procédures soit alors le seul changement opérationnel, la transition vers un fonctionnement qualifié d’industriel est perçue comme un progrès significatif.
Bien sûr, des gains importants d’efficacité dans le traitement des maintenances auraient probablement pu être atteints par la mise en place de procédures simples, sans pour autant externaliser l’activité. Mais l’externalisation est ici le chemin le plus court vers la maturité et l’efficience.
Il semble nécessaire de pouvoir déterminer a priori les situations où l’on pourra éviter de doubler les postes de chef de projet et où la dépendance ne sera pas à craindre.
Il convient en particulier :
- de disposer d’une règle pour la durée des contrats de TMA,
- de savoir dans quel cas on peut s’abstenir de contrôler le détail des modifications des sous-traitants,
- d’établir ce qui rend l’externalisation de certaines applications plus risquée que pour d’autres, et la TMA plus que l’infogérance de production.
Une approche économique
Les économistes se sont en effet interrogés depuis longtemps pour savoir dans quel cas il convenait de réaliser une activité dans l’entreprise, au lieu de faire appel au marché pour l’obtenir.
Le premier constat consiste à considérer qu’une activité largement disponible sur le marché sera faite, en interne, à un coût supérieur. Le fournisseur bénéficie d’économies d’échelle ou de gamme s’il produit sur place, auxquelles il peut encore ajouter des économies pour les activités délocalisées dans les pays à bas coût. A contrario, dans l’entreprise, les variations de charge ne sont pas compensées par la taille du marché interne et les compétences ne sont pas mutualisées.
Ces éléments concernent le coût « brut » de l’activité. On doit y ajouter le coût de « gestion » de cette activité. Par exemple, les coûts d’établissement et de suivi des contrats et les coûts de la réversibilité en cas d’externalisation. Le coût de gestion d’une activité maintenue au sein de l’entreprise correspond au coût du management des ressources internes.
La microéconomie est également sensible à la notion « d’incitation ». Dans ce domaine, l’avantage est aussi donné à l’externalisation : il apparaît plus simple de « motiver » un sous-traitant par des primes dans le cadre d’un contrat, que d’actionner des primes internes dans un cadre salarial. De même, il est beaucoup plus simple de révoquer un sous-traitant que de sanctionner des équipes internes. C’est le « coût de l’équité » interne et le prix de la solidarité au sein de l’entreprise. On voit que les raisons d’externaliser la maintenance ne manquent pas.
Dérives comportementales
Il reste des critères qui poussent plutôt à conserver des activités en interne, par exemple des critères comportementaux. Le constat est ici que les différents acteurs de l’entreprise et les différentes entreprises les unes par rapport aux autres n’ont pas de comportements angéliques.
Les intérêts diffèrent, et il convient de se prémunir, notamment par contrat, des comportements opportunistes des uns et des autres, et donc d’identifier les situations où ces risques pourraient se présenter. D’où les contrats de travail pour régler les relations au sein de l’entreprise et les contrats commerciaux entre entreprises. Au sein d’une même société, les risques comportementaux sont faibles, et les salariés poursuivent « naturellement » les mêmes objectifs que l’ensemble de l’entreprise.
Le risque de comportement « opportuniste » est beaucoup plus significatif lors de contrats commerciaux de long terme. Plus exactement, c’est la durée d’exécution des contrats, l’incertitude qu’elle engendre et l’impossibilité de tout formaliser dans le contrat initial qui génèrent des situations où client et fournisseurs peuvent être tentés de tirer la couverture à eux. C’est ainsi que s’analyse le cas du client mis progressivement en situation de « dépendance ». Concrètement, plus les applications sont « banalisées », plus il est intéressant d’en sous-traiter la maintenance, car la situation de dépendance est moindre.
Le cas des applications à base de progiciel
Non seulement on peut trouver des compétences sur le marché et faire jouer la concurrence lors du choix du sous-traitant, mais en plus, les incertitudes dans le déroulement à venir des opérations seront limitées face à un éventuel comportement opportuniste du fournisseur.
Il reste simplement à définir correctement la sous-traitance avec les éléments suivants :
- le catalogue des interventions types,
- le prix associé,
- les modalités et procédures de transmission des demandes d’évolution,
- la technique de livraison et de recette,
- l’organisation du suivi de la prestation,
- les modalités de sortie du contrat, à mettre en place de façon professionnelle.
Cependant, il est possible que l’on ne puisse pas prévoir l’ensemble des interventions à venir sur une application, qu’il s’agisse d’un progiciel ou non. Parfois, le volume et la complexité des maintenances évolutives débordent la liste des types d’intervention initialement prévus. Pour éviter d’avoir à engager une négociation commerciale avec un fournisseur unique sur un ensemble imprévu d’évolutions, les contrats limitent d’emblée leur portée à une liste définie d’interventions, caractérisées par leur nature ou leur taille.
Cette prudence découle d’une faiblesse de l’ingénierie logicielle par rapport à d’autres secteurs d’activités : la détermination des efforts de développement et l’élaboration d’un tarificateur reposant sur des unités d’œuvre mesurables est une entreprise très complexe en informatique. De fait, la recherche de la limitation du risque financier conduit à distinguer de façon volontariste les évolutions qui relèvent de la maintenance de celles pour lesquelles la DSI lancera un appel d’offres.
Le cas des applications spécifiques
Dans ce cas, la SSII va devoir acquérir des compétences particulières pour en assurer la maintenance. Il faudra que ses ingénieurs apprennent l’application concernée. De plus, cet apprentissage ne pourra généralement pas être réutilisé chez aucun autre client du fournisseur.
L’effort à déployer pour comprendre l’application doit être évalué. Il est d’autant plus faible que l’application, bien que spécifique vis-à-vis du marché, est facile à prendre en main. C’est-à-dire bien écrite, bien documentée, complétée par des jeux d’essais et de tests. Plus la maintenance de l’application est facile, plus l’infogérance de celle-ci est aisée…
L’entreprise cliente, pour sa part, devra s’assurer, à l’issue de la phase de prise en main, que le fournisseur a bien acquis les connaissances nécessaires. Ces clauses sont effectivement présentes dans les accords et les contrats prévoient les « examens » de vérification de connaissance à l’issue de la phase initiale.
Il est plus rare que l’entreprise s’assure de façon aussi formelle que les compétences se maintiennent au fil du temps, alors même que le turnover chez le fournisseur rend ce savoir éphémère. La pratique est plutôt de considérer que le fournisseur se doit de maintenir cette compétence tout au long du contrat et que le client ne manquera pas de s’apercevoir d’une baisse de niveau.
L’ampleur de cette dépense spécifique détermine la durée du contrat. Plus la dépense de prise en main est conséquente, plus il conviendra de faire un contrat de longue durée car chaque changement de sous-traitant introduit un nouveau coût et diminue la performance globale de l’opération. Les fournisseurs mettent plutôt en avant un autre argument pour justifier une durée plus longue des contrats de TMA sur les applicatifs spécifiques : il leur faudrait plus de temps pour rationaliser et mettre aux normes ces applicatifs.
Cette dépense supplémentaire montre, s’il en était besoin, qu’il faut éviter de détenir des logiciels inutilement particuliers, dès lors que l’équivalent existe sous forme de progiciels. Les logiciels « exotiques » écrits dans des langages ésotériques, des architectures peu orthodoxes, des infrastructures maison, dont on sait déjà que l’emploi représente un coût souvent prohibitif à la longue, sont également plus faiblement externalisables. Lorsque l’application reste essentiellement basée sur un logiciel du marché, le risque que les ingénieurs de la SSII ne dominent pas rapidement les particularités de leur client est faible.
Quels sont les risques de la TMA ?
La baisse de la qualité de service
La difficulté de transférer la compétence fonctionnelle vers les équipes externes chargées de la TMA peut conduire à une baisse de la qualité de service, principalement dans les premiers temps. Il ne faut pas négliger également les conséquences dues aux changements fréquents d’affectation des ressources externes.
La dépendance
Les sociétés de TMA ont un intérêt évident à garder seules la maîtrise des applications pour créer une situation de dépendance et donc une assurance de revenus futurs.
L’accroissement des budgets
Si un suivi rigoureux des demandes de maintenance n’est pas assuré, on peut être confronté à une évolution exponentielle des demandes, ce qui conduit à un accroissement des budgets, donc à un résultat inverse de celui que l’on cherche.
La perte de la maîtrise du système d’information
Dans la mesure où les sociétés de TMA reprennent l’ensemble des actions sur les applications informatiques, il y a un risque de perdre la compétence fonctionnelle des équipes internes sur des applications qui peuvent être stratégiques pour l’entreprise.
Comment prévenir ces risques ?
Au-delà de ces quelques recommandations générales, il est nécessaire de mettre en place une démarche méthodologique et des bonnes pratiques.
Comment faire pour éviter la baisse de la qualité de service ?
- Mettre l’accent sur les phases de transfert de compétence, prendre soin à la qualité des documentations.
- Demander aux sociétés de TMA de s’engager sur des conventions de service contractuelles avec des pénalités associées.
- Ne pas sous-estimer la charge à consacrer au pilotage des TMA : 5% à 10% du budget de la maintenance selon le contexte.
- Comment faire pour éviter la dépendance vis-à-vis des sociétés de TMA ?
- Se donner la possibilité de changer de société ou de confier à des sociétés tierces des évolutions fonctionnelles majeures.
- Garder la maîtrise fonctionnelle et la maîtrise d’œuvre des applications informatiques.
- Prendre soin à la rédaction et à la structuration des contrats.
- Impliquer le service achats pour mettre en place un suivi contractuel permanent.
Comment faire pour éviter l’explosion des budgets ?
- Éviter les relations directes entre la maîtrise d’ouvrage (les utilisateurs) et les sociétés de TMA.
- Forfaitiser les évolutions fonctionnelles mineures annuellement, en fixant un nombre de jours maximal et en gérant un portefeuille de demandes en cohérence avec le budget.
- Prévoir à l’avance les évolutions majeures, les intégrer dans les plans annuels de développement.
- Mettre en place un pilotage de l’activité TMA en interne.
Comment faire pour garder la maîtrise fonctionnelle des applications ?
- Garder un chef de projet interne pour chaque applicatif. Ce chef de projet sera impliqué dans toutes les actions et sera l’intermédiaire entre la maîtrise d’ouvrage et la société de TMA.
- Imposer contractuellement à la société de TMA une mission de transfert de compétence permanent vers les équipes informatiques internes.
- Piloter et suivre les actions de la société de TMA pour s’assurer de leur transparence.
Cet article a été rédigé pour Best Practices par Alain Sacquet, consultant.