2.6. L’utilisation du système
2.6.3.4. Prestataire de maintenance
2.6.3.4.1. Coût de la maintenance
La maintenance annuelle coûte au moins 5 à 10% du prix du logiciel. L’entreprise responsable de la maintenance corrective a typiquement un contrat de 3 ou 4 ans. Il est ensuite difficile d’en changer car elle peut “ verrouiller ” techniquement les évolutions et dicter ses prix. Il faut donc pour les évolutions majeures mettre le mainteneur en concurrence, le mainteneur jouant alors le rôle de maître d’œuvre et assurant la bonne intégration avec l’existant… Bien sûr, le mainteneur reste bien placé pour proposer des prix inférieurs.
Les budgets de maintenance sont difficiles à estimer a priori et souvent sous-évalués. Une difficulté supplémentaire vient du fait que la maintenance évolutive est souvent considérée comme faisant partie des crédits de fonctionnement (titre 35.43 en comptabilité publique). Mais en principe, la maintenance corrective doit relever du fonctionnement et la maintenance évolutive des crédits d’investissements ; pour un marché de maintenance globale, il faut donc un marché à double imputation (Ex. de CORALY - DDE69).
2.6.3.4.2. Tierce maintenance applicative
Peut-on sous-traiter la maintenance à un autre prestataire que le réalisateur ?
C’est ce qu’on appelle la tierce maintenance applicative (TMA) ; c’est souhaitable dans la mesure où cela oblige à avoir un logiciel bien documenté et rend l’exploitant moins dépendant de son prestataire de services informatiques. L’analyse des offres pour une TMA est grandement facilité si on a défini a priori les critères de qualité attendus du logiciel (qualimétrie du code et de la documentation).
L’intérêt pour l’utilisateur est de mieux maîtriser la prestation et notamment ses coûts.
La Commission Centrale des Marchés et la Direction de la Concurrence et des Prix sont attentives à ce que les principes de libre concurrence soient respectés, et à tout ce qui peut ressembler à du prêt illégal
de main-d'œuvre : on ne peut passer un marché avec un fournisseur de prestations intellectuelles sans préciser l'objet de ces prestations (en gros, le travail en régie est interdit). Les évolutions logicielles ne peuvent donc pas se faire au fur et à mesure de l'expression des besoins. Malheureusement, aucune solution miracle n'est proposée par les censeurs, à charge pour les MOUV de toujours savoir ce qu'ils veulent développer, avec parfois 3 ans d'avance...
Les marchés de réalisation devraient comprendre une phase de formation du prestataire TMA, et la fourniture d’une plate-forme de développement (c’est dorénavant le cas à la Ville de Paris).
Pour l’instant, le retour d’expérience reste limité en la matière, mais la DDE13, comme le SIER, ainsi que la DDE69 et la Ville de Paris, sont en train de travailler sur leurs contrats de maintenance informatique pour leur SAGT. Il serait intéressant d’interroger d’autres grands exploitants, comme le CIGREF5, la RATP, la SNCF ou des concessionnaires d’autoroutes pour progresser dans ce domaine.
2.6.3.4.3. Exemples
• A la Ville de Paris, la maintenance du système (sauf des PMV et caméras) est prise en charge par le groupement GECIR comprenant EDF pour les équipements et la Générale des Eaux (Mercur) pour le logiciel.
• A Marseille, le système MARIUS a été audité en 96 ; le réalisateur du logiciel (Sagem) en est aussi le mainteneur
• A Lyon, le système CORALY n’est pas encore entré en phase de maintenance (99).
2.6.4. Le retrait
C’est l’ultime étape du cycle de vie. Elle consiste à mettre en place des procédures de changement de système tout en pérennisant les données et éventuellement les fonctionnalités du système. Cette étape est rarement étudiée en tant que telle et est plus souvent analysée dans la phase d’étude préalable d’un nouveau système devant assurer la succession de l’existant.
2.7. Synthèse
Nous reprenons dans le tableau qui suit les phases et sous-phases du cycle de vie, en indiquant comment se partagent les responsabilités dans un projet « typique ». Ce découpage en phases va nous être utile pour le classement des contributions du groupe de travail, dans la partie suivante.
phase responsabilités
Études préalables Opportunité, faisabilité validation MOUV
Montage du projet Montage et suivi du projet MOEF+T
Développement - Définition du système
Expression des besoins, cahier des charges et DCE
rédigée par MOUV, choix des MOET et MOEF
Spécifications REA, approuvée par MOEF et MOET Maquettage et prototypage REA, approuvée par MOEF et MOET Développement - Conception Conception (générale puis
détaillée)
REA validée par MOET6
Développement - Réalisation Programmation REA
Tests unitaires, mise au point REA, validés par MOET7
Tests d’intégration REA, validés par MOET4
Réception8 usine REA, validés par MOEF et MOET4
Développement - Mise en service Intégration sur site pilote, Vérification d’Aptitude au Bon Fonctionnement (sur site pilote)
REA, validés par MOEF et utilisateurs
Vérification de Service Régulier (opérationnel) et réception finale
utilisateurs en exploitation, validés par MOEF
Déploiement en exploitation, (y compris accompagnement)
Utilisation du système - Fonctionnement
Exploitation et administration utilisateurs
Utilisation du système - Maintenance
Maintenance corrective REA (éventuellement une autre entreprise) + MOET
Maintenance évolutive REA (éventuellement une autre entreprise) +
MOET et MOEF
6 La MOET n’est pas engagée par une approbation – tout du moins en conception détaillée – mais les documents doivent lui être remis.
7 MOET et MOEF peuvent demander à participer à ces phases, mais là non plus, ne sont pas engagées (seules la VABF et la VSR sont contractuelles).
8 On distingue parfois le terme de ‘recette’ (où un test est « déroulé »), comme lors de la sortie d’usine, et le terme de ‘réception’, où le client accepte le produit, après une éventuelle période d’essai (cas de la VSR).
Utilisation du système - Retrait Retrait (migration) MOUV
REA : réalisateur ; MOE : maître d’œuvre (Fonctionnel ou Technique) ; MOUV : maître d’ouvrage.