À quoi sert un Ingénieur en Système d'Information ?

L’ingénieur en Système d'Information (SI) fait partie de la catégorie « Ingénieur informatique », dans lequel se retrouve les Ingénieurs Développeurs, Ingénieurs Réseaux et Télécoms, Ingénieur en informatique Industrielle etc.

Son rôle majeur est de piloter le bon fonctionnement du Système d’Information de l’entreprise en assurant la cohérence des projets IT avec celui-ci.

Quel est le rôle de l’Ingénieur SI dans un projet IT ?

Le rôle de l’Ingénieur SI dans un projet IT est d’être garant·e de l’intégration du projet IT dans le fonctionnement du SI. Il/Elle possède une forte capacité d’adaptation et de montées en compétences sur des processus métiers, de nouveaux outils informatiques, de nouveaux langages ou nouvelles tendances… L’Ingénieur SI dispose donc d’un profil généraliste avec une appétence forte pour la remise en question et la veille de tendance technique, à savoir :

- Structurer l’ensemble du portefeuille projets : choix de la solution, phasage, procédures, gouvernance, planning, budget, ressources et moyens… ;

- Identifier et anticiper les risques ;

- Assimiler et traduire les besoins métiers auprès du Service informatique ;

- Préparer les développements informatiques ;

- Anticiper les impacts des projets IT sur le Système d’information ;

- Valider la cohérence des choix IT réalisés par les Services informatiques ;

- Documenter le Système d’information en tenant compte des évolutions techniques ;

- Accompagner le maintien des bonnes pratiques ;

- Garder une vision globale du SI de l’entreprise tout au long du développement de celui-ci ;

- Prévenir et assurer la rationalisation des solutions intégrée au SI.

Qu’est-ce que l’Ingénieur SI ne fait pas ?

Bien que l’Ingénieur SI ait un profil généraliste, il/elle n’est pas censé réaliser toutes les tâches qu’incombent un projet IT telles que :

- La gestion opérationnelle des activités informatiques – Ce poste est celui d’un·e DevOps ou d’un Administrateur. En revanche, l’ingénieur SI peut intervenir sur les besoins des opérationnels telles que l’amélioration des outils de gestion de projet, la conception d’outil de suivi, la définition d’indicateurs, la résolution d’incidents trop récurrents…

- Le développement informatique – Ce poste est celui d’un·e Développeur·se dont les compétences sont spécifiques en fonction des solutions et du langage qu’elles requièrent. L’ingénieur SI doit plutôt intervenir dans le pilotage global d’un projet de développement si celui-ci sollicite le Système d’information

- L’administration et le paramétrage d’outils - Ce poste est celui d’un·e administrateur·rice. L’Ingénieur intervient davantage en amont pour la cohérence des paramétrages avec les besoins Métier et le bon fonctionnement du SI

Quand doit-on faire appel à un·e Ingénieur SI ?

Il est conseillé d’être accompagné par un·e Ingénieur SI pour chaque projet qui a un impact fort sur le Système d’information, et ce, dès la détection du besoin jusqu’aux premiers mois de mise en place.

Quelle est la différence entre un Ingénieur SI, un Informaticien et un Chef de projet technique ?

Le/La chef de projet technique coordonne la réalisation d’un ou plusieurs projets informatiques, de la formalisation du besoin jusqu’à la mise en production. L’ingénieur SI, quant à lui ou elle, coordonne les sujets des Chefs de projet qui ont un impact sur le Système d’information. Il/elle a une vision globale de l’ensemble des projets IT afin d’assurer le maintien du Système d’information au fil des avancées des différents projets.

Quant à l’Informaticien·ne, il/elle est sollicitée pour réaliser des actions qui nécessitent une expertise technique spécifique : proposer une solution, la développer, l’intégrer et la maintenir. Il/elle peut aussi assurer le support technique pour les utilisateurs. C’est un rôle plus opérationnel que stratégique.



Pourquoi structurer correctement un projet informatique ?

#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


(Ré)organiser son équipe lors du passage du télétravail au présentiel

Avec la reprise progressive de l’économie, nous sommes tous tentés d’accélérer des projets au sein de l’entreprise pour « rattraper le retard”. Afin de ne pas perdre les bonnes résolutions qui ont pu être prises au cours d'une organisation à distance, voici un exemple d’organisation à mettre en place pour accompagner progressivement la reprise sans reproduire les erreurs et les mauvaises pratiques mises en exergue au cours des derniers mois. Le passage du travail à distance au travail en présentiel est une opportunité pour faire le bilan et améliorer son organisation, autant profiter du rythme ralenti de l’été !

Étape n°1 – Faire un bilan managérial

Le premier réflexe actuellement observé est la reprise à 100% des projets d’entreprise, et ce, comme si rien n’avait été troublé pendant plusieurs mois. Nous n’avons pas tous vécu le télétravail de la même manière, une reprise trop brutale risque de générer davantage de désengagement, de stress et de surcharge de travail.

Prendre le temps de faire le point sur l’état managériale et l’organisation du travail peut permettre de désamorcer de potentiels tensions mais aussi de pérenniser les bonnes pratiques qui ont été expérimentées et validées lors d'une organisation à distance, et ce, en mettant en place les actions suivantes :

- Réaliser un point individuel sur l’état de santé (physique et mentale) et de l’état de motivation de chaque collaborateur ;

- Envoyer un sondage anonyme pour identifier par service :

  • les retours positifs et négatifs vécus en télétravail ;
  • les bonnes et mauvaises habitudes de travail ;
  • les points positifs et négatifs sur les outils utilisés ;
  • les compétences nouvelles qui ont été développées ;
  • des recommandations pour mieux faire.

- Analyser et centraliser les résultats du sondage afin d’en dégager un plan d’action voire un plan d’accompagnement à communiquer puis à mettre en place selon les services.

Étape n°2 – Revoir la priorisation des projets

Bien que l’économie se relance, votre écosystème s’en est-elle sortie indemne ? Les investissements engagés avant la crise sont-ils toujours pertinents ? Vos clients sont-ils prêts à consommer de la même manière ? Vos fournisseurs ont-ils été impactés ? Vos projets d’entreprises sont-ils toujours cohérents avec un contexte de crise ? Avec le même ROI ?

Le bilan managérial du confinement terminé, la seconde étape consiste à revoir les projets en cours et à venir pour :
- Valider la cohérence et la pertinence des projets ;
- Réduire les dépenses inutiles ;
- Réévaluer le ROI et les niveaux de priorités compte-tenu du contexte de reprise ;
- (Re)Mettre en place des bonnes pratiques de gestion de projets ;
- Évaluer les manques et les besoins.

Les actions suivantes permettent de faciliter la prise de décision :
- Identifier l’état d’avancement de chaque projet ;
- Analyser les actions à venir, en cours et en phase d’étude pour évaluer les coûts associés (en ressources, en temps et en budget) ;
- Identifier les moyens et les ressources humaines disponibles à distance, en présentiel ;
- Identifier les ROI et les impacts ;
- Valider les niveaux de priorité vis-à-vis des données préalablement récoltées ;
- Revoir le planning et étudier sa faisabilité selon les moyens et les ressources humaines disponibles ;
- Définir ou redéfinir une organisation tirée de l’étape n°1, selon les planning, les moyens et les ressources identifiés plus tôt.

Ces étapes ont pour objectifs de renforcer la maîtrise des projets et la confiance des collaborateurs suite à une période trouble. La reprise est la période propice pour revoir et améliorer les modes d’organisation tout en maintenant la relance opérationnelle de l’entreprise. Cette accalmie remet au centre les besoins essentiels de l’entreprise.