Un bon contrat d’infogérance dépend de plusieurs éléments dont la bonne estimation des prestations.
L’étude et la maintenance qui figurent dans le cahier des charges varient selon les exigences.
Le contexte fonctionnel et technique doit être suffisamment précis pour éviter toute interprétation ou malentendu.
1. L’estimation des prestations
Les prestations d’infogérance dépendent directement des exigences, et du contexte fonctionnel et technique.
Les études d’infogérance parfois insuffisantes peuvent occasionner des malentendus ou contentieux.
Par exemple, une application seule n’est pas un contrat d’infogérance puisqu’il n’ y a pas de récurrence. On parle dans ce cas précis de Tierce Maintenance Applicative (TMA).
Un contrat d’infogérance globale comporte la dimension d’ « étude » qui élargit le champ des prestations (développement, extension, modification, adaptation) jusqu’à la migration ou la refonte des applications si changement d’environnement.
Au vu de tous ces différentes options, produire des études avec engagement de résultat tient de l’impossible. L’engagement de résultat est donc forfaitaire en raison des difficultés d’estimation.
La mesure ou effort de la charge (jour x homme) de travail nécessaire à la prédiction d’un logiciel repose sur le calcul d’unité d’oeuvre spécifique basé sur le nombre et la complexité des fonctionnalités à réaliser ainsi que des données à traiter.
La traditionnelle techniques d’estimation est celle dite des points de fonction IFPUG (International Function Point User Group).
Elle prend en charge les besoins fonctionnels mais également les performances, la sécurité, la robustesse, l’ergonomie…
Tous les facteurs sont pris en compte :
- techniques : outils utilisés,
- humains : compétences et expériences des développeurs, qualité d’encadrement, productivité,
habitude des intervenants… - niveau des exigences hors du champ fonctionnel : sécurité, disponibilité, performance..
La connaissance insuffisante des besoins à ce stade de l’étude, ainsi que l’environnement technique évolutif crée une complexité qui peut se gérer différemment :
- soit on fait une définition précise des exigences du développement, d’évolution, et de maintenance,
- soit on choisit une évaluation des prestations au coup par coup avec un coût variable mentionnés dans le contrat,
- soit les prestations sont comprises dans un budget forfaitaire annuel défini et contrôlé sur chaque exercice,
- soit les prestations d’étude font l’objet d’avenant au contrat principal avec le risque pour le client de se voir imposé des prix non contrôlés.
Faire une bonne estimation passe par une bonne étude d’infogérance.
Plus de détails sur l’étude d’infogérance.
2. Les cycles de gestion de projet
Les extensions de systèmes existants, les développements nouveaux ou la refonte d’applications suivent des processus maîtrisés. Ils mettent en oeuvre trois principaux cycles de vie du logiciel : le cycle classique en V, le cycle incrémental et la méthode agile.
Le cycle en V
Il comporte les étapes suivantes :
- spécifications fonctionnelles générales et détaillées, – conception technique générale et détaillée,
- programmation,
- tests unitaires, tests d’intégration,
- test utilisateur et site pilote,
- migration et déploiement,
- maintenance corrective et évolution.
Le cycle incrémental
Basé sur le principe du recyclage développé et son amélioration progressive ou enrichissement continu, au travers de cycles successifs suivants :
- définition des besoins,
- conception de la maquette,
- développement et test de la maquette,
- conception de prototype,
- développement et test du prototype,, itération éventuelle, – intégration et recette,
- bêta tests et déploiement du système,
- évolution du système opérationnel.
La méthode Agile
Par opposition aux précédentes, le cycle agile permet de développer le produit et le mettre au point de manière progressive.
Il privilégie le dialogue entre toutes les parties prenantes du projet (clients, utilisateurs, développeurs et autres professionnels), la souplesse et la capacité à modifier les plans et la rapidité de livraison.
Les douze principes de l’équipe agile Scrum
- Satisfaction du client, rapidité de livraison et qualités fonctionnelles, – Accueillir positivement les changements de besoins,
- Cycles de livraisons plus courts,
- Collaboration entre utilisateurs et développeurs,
- Recruter les personnes les plus motivées,
- Communication en face à face,
- La mesure du travail se fait sur le fonctionnement du logiciel,
- Rythme de développement soutenu et continu,
- Excellence technique et design,
- Simplicité avant tout,
- Auto-gestion des équipiers,
- Revue et optimisation du fonctionnement
3. Le recours au progiciel
La mise en place de nouveaux systèmes se fait à partir de progiciels standards. Les développements s’assimilent parfois à du paramétrage ou de l’intégration de systèmes plutôt qu’à de véritables développements en langages classiques ou des outils orientés objets.
Chacun a sa méthodologie de développement et permet aux développeurs comme aux utilisateurs d’ accélérer les projets pour un coût inférieur. Le retour de ces pratiques impose d’accepter la remise en cause organisationnelle ou fonctionnelle.
La logique du progiciel s’impose contre celle de l’organisation en place.
4. La maintenance applicative
Maintenance curative
Les interventions curatives ont pour objectif de corriger rapidement les effets d’une anomalie de fonctionnement après son déroulement ( ex : réinitialiser un système planté).
Maintenance corrective
L’intervention est corrective dès lors qu’elle permet de corriger les causes du défaut. Elle prend diverses formes :
- intervention de contournement sans modifier le logiciel suivie d’une intervention à froid pour
correction du logiciel, - intervention sur site, à chaud.
Elles doivent toutes deux être tracées et documentées. Elles font l’objet de test de vérification avant la mise en production puis doivent être validées après au moins un cycle opérationnel.
L’engagement de résultat
Il peut être défini comme suit : le prestataire doit respecter les procédures définies pour la résolution des incidents selon leur gravité (bloquant, perturbateur, mineur). et doit répondre dans un délai maximal de une heure ouvrée à tout incident bloquant.
Maintenance adaptative
L’obsolescence du matériel informatique implique son remplacement. La performance d’un système repose sur la compatibilité de ses éléments. Le prestataire s’engage sur la maintenance adaptative de tous les éléments du logiciel applicatif et l’amène à :
- avoir à disposition la documentation,
- vérifier et tester la performance.
Maintenance évolutive et modificative
Dans le cas où le client souhaite apporter des modifications ou améliorations, le prestataire établira un devis sur la base de la demande du client. Les modifications sont traitées comme un petit projet au forfait.
Les modifications feront l’objet de :
- une recette par le client,
- une mise à jour de la documentation de l’application,
- un respect des normes et standards définis par le client.
Tous ces éléments figurent dans : Tout savoir sur le cahier des charges d’infogérance.
5. Production, industrialisation et automatisation
Les types de prestations :
- définir et mettre à jour l’architecture
d’exploitation de chaque application, - industrialiser le logiciel (conformité,
standards, procédures). - rédiger les JCL, scripts et fichiers de
commandes, paramétrage des automates, mise au point du dossier d’exploitation,
- vérifier le fonctionnement (performances, ressources, temps, comportement),
- bascule des programmes et archivage de version,
- suivi des cycles et corrections.
6. L’assistance des études aux utilisateurs
Cette prestation consiste à fournir aux utilisateurs de deuxième niveau des applications développées ou maintenus par le prestataire (le premier niveau est le centre d ‘appels ou assistance téléphonique). Il faut prendre en compte les demandes de type : aide, formation, conseils :
- les demandes : paramétrages spécifiques, planning d’exploitation, incident ou dysfonctionnement,
- l’aide concerne des difficultés d’utilisation : lorsque l’assistance téléphonique ne trouve pas de solutions, et que le problème ne concerne pas l’exploitation,
- formation : sil y a un changement d’utilisateur, des séances de formation ou d!information sont nécessaires,
- le conseil consiste à aider l’utilisateur à formuler une demande de travaux spécifiques, d’évolution ou d’amélioration de son application.
