#1 – Qu’est-ce qu’un projet informatique ?

Un projet informatique est un projet dont les livrables sont constitués d’outils (logiciels, applications web ou mobiles, infrastructure…), de méthodes ou de services informatiques (infogérances, dépannage…).

Il s’articule autour de différents acteurs :

  • Les sponsors : Acteur(s) qui défend la pertinence et les enjeux d’un projet pour débloquer un budget
  • La DSI ou le service informatique (en fonction de la taille de la structure) : Responsable de la validation, du paramétrage et de l’intégration de la solution informatique
  • Le(s) chef(s) de projet : Acteur(s) transverse(s) qui traduit les besoins du Métier vers l’IT et les impératifs de l’IT vers le Métier (tests, spécifications fonctionnelles etc.)
  • Les services métiers : Acteurs sollicités pour leur expertise métier sur un projet car directement impactés (en tant qu’utilisateurs ou administrateurs notamment)
  • Les fournisseurs et les experts : Prestataire de service, éditeurs de logiciel, consultants…

Cet article vous présente les risques majeurs d’un projet informatique mal structuré et comment détecter les facteurs d’un manque de structuration afin de les solutionner en amont.

#2 – Quels sont les risques d’un projet mal structuré ?

  • Le projet est livré avec des retards importants. Ces retards surviennent quand on omet d’intégrer et de suivre régulièrement :
    • La disponibilité des acteurs du projet (incluant le Métier)
    • La revue des ressources (Compétences) et des moyens (Outils) nécessaires au bon déroulé du projet
    • Le suivi d’un planning trop ambitieux ou un planning incomplet
    • La communication interne
  • Le budget initial est dépassé avec des coûts imprévus. Les surcoûts sont liés à des éléments qui n’ont pas été anticipés :
    • La rédaction du cahier des charges comprenant les exigences techniques IT ou Métier
    • La cartographie des utilisateurs finaux
    • L’adéquation des spécificités fonctionnelles avec l’environnement technique existant
    • L’anticipation du planning et des imprévus
  • La solution est peu ou pas utilisée. Elle peut ne pas convenir aux utilisateurs finaux et donc ne pas être utilisée, et ce, quand plusieurs actions n’ont pas été abouties :
    • La conduite d’ateliers auprès des utilisateurs, auprès des métiers impactés
    • La cartographie des utilisateurs finaux et leurs usages
    • La validation des fonctionnalités proposées par la solution en accord avec le cahier des charges et les exigences
    • La communication interne entre les différentes parties prenantes
    • Les tests utilisateurs
    • L’accompagnement au changement des utilisateurs finaux
  • La maintenance coûte plus chère que prévue. En fonction du déploiement et de(s) solution(s) choisie(s), la maintenance génère des coûts plus élevés que prévus en raison de :
    • Manque d’adéquation entre les spécificités fonctionnelles et l’environnement technique existant
    • Commande de fonctionnalités qui ne figurent pas dans le cahier des charges
    • Peu de cadrage des développements spécifiques
    • Manque d’anticipation du planning et des imprévus
    • Recettes fonctionnelles et techniques incomplètes
  • L’entreprise est dépendante de ses expertises externes (Éditeur, Prestataires, Consultants etc.) La manque d’autonomie dans votre relation avec un Éditeur peut poser des problèmes de maîtrise des coûts et des temps pour des interventions mineures. Cette dépendance est le résultat :
    • D’absence de suivi des actions de l’Éditeur ou d’outil de reporting central
    • D’un cahier des charges imprécis quant au planning, aux ressources et aux utilisateurs concernés
    • D’un besoin qui n’a pas été traduit en fonctionnalité, en actions concrètes (le fameux : « Il me faut un site »)
    • D’un manque de rigueur dans les tests et les validations signées
  • Personne n’est disponible : Vos collaborateurs ont d’autres tâches à réaliser au quotidien. Un projet informatique même s’il est essentiel n’est pas toujours considéré comme prioritaire. Par manque de sensibilisation et de communication interne, vous risquez de manquer de plusieurs compétences, au mieux vos délais seront fortement retardés.

#3 – Comment mieux appréhender les facteurs de risque d’un projet informatique mal structuré ?

Quand le cahier des charges est incomplet

Le cahier des charges doit intégrer à minima les éléments suivants :

  • La présentation du besoin et le détail des fonctions attendues
  • La liste des exigences métiers et techniques (IT)
  • La cartographie des utilisateurs finaux
  • L’analyse des spécificités fonctionnelles avec l’environnement technique existant

Le cahier des charges doit être validé par toutes les parties prenantes avant de lancer les phases de négociations commerciales.

Quand le planning est incomplet

Un planning projet est découpé en phase dont voici la liste :

  • Définition du besoin fonctionnel et technique
  • Cadrage du projet
  • Validation de la solution et/ou du prestataire
  • Développement
  • Tests
  • Déploiement
  • Conduite du changement

Le planning doit intégrer :

  • Le découpage des phases dans le temps
  • Les actions par phase
  • Les acteurs associés à chaque action et/ou phase (responsable, valideur, consulté, informé) ainsi que leurs disponibilités
  • Le temps nécessaire pour réaliser chaque action
  • Les livrables pour chaque action et/ou phase

Quand les critères de choix du Prestataire/Éditeur ne sont pas clairs ou inconnus

Le prestataire et/ou l’éditeur doivent être choisis de manière objective grâce à ces éléments :

  • L’adéquation de l’offre du Prestataire/Éditeur avec le cahier des charges
  • La pertinence des préconisations et une bonne reformulation du cahier des charges 
  • Le coût total du produit et de sa maintenance
  • Le coût des expertises éventuelles (atelier, test, audit etc.)
  • La réactivité
  • La documentation et autres supports d’accompagnement des utilisateurs

Quand l’analyse de l’environnement technique IT est incomplète

L’analyse de l’environnement technique intègre :

  • La revue de l’existant
  • Un référentiel des moyens et ressources techniques
  • La cartographie des flux de données
  • La validation de la faisabilité des spécificités fonctionnelles ou des alternatives si tout n’est pas faisable
  • Des spécifications techniques

Quand le plan de communication projet est inexistant

Plus vous communiquerez régulièrement, mieux vous préparerez vos utilisateurs à l’arrivée d’une nouvelle solution informatique, et plus vous sensibiliserez aux enjeux d’un tel projet pour mettre toutes vos parties prenantes au même niveau d’information tels que :

  • Les enjeux du projet et ses bénéfices
  • Les avancées et blocages
  • Les points d’attention et les problèmes résolus
  • Les mobilisations requises (ateliers, tests, questionnaires etc.)
  • Le plan d’accompagnement au changement (atelier, formation etc.)

En conclusion

Un projet informatique se structure donc avant son lancement. Si votre projet recense trop de facteurs de risque, il est préférable de le passer en revue afin d’éviter les retards, les surcoûts, le désengagement et les projets abandonnés