Exemple de thèse professionnelle en Informatique

ABSTRACT 4
INTRODUCTION 5
Partie I : LES CONCEPTS ET LES ETUDES SUR L’IMPLICATION DE L’OBSOLESCENCE DANS LA GESTION D’UN PROJET INFORMATIQUE ET TECHNOLOGIQUE
Chapitre I : APPLICATION DE LA GESTION DANS LA CONDUITE D’UN PROJET INFORMATIQUE ET TECHNOLOGIQUE 6
La gestion de projet sous le prisme de l’informatique et la technologie 6
Cycle de projet dans le contexte informatique 8
Acteur clé 9
Le cycle de vie des produits dans un projet informatique 9
Chapitre II : L’OBSOLESCENCE AU CŒUR DU CYCLE DE PROJET INFORMATIQUE ET TECHNOLOGIQUE 11
Les formes de l’obsolescence qui affectent le projet 13
Entre gestion d’un risque financier et technique face à l’obsolescence 17
Le risque pour l’image et la pérennité du projet 17
Le risque de sécurité 19
Partie II : RECHERCHE ET ANALYSE EMPIRIQUE
Chapitre I : MAITRISE DU RISQUE D’OBSOLESCENCE AUX DIFFERENTS STADES DU PROJET 19
Contrôle avant-projet : état des lieux des technologies existantes et futures 19
Suivi dans la phase de construction et réalisation du projet 23
Mise à jour ou mesure pour la pérennisation du projet 32
Chapitre III : ANALYSE ET RECOMMANDATIONS 35
Méthodologie et hypothèses 35
Aborder la gestion de l’obsolescence comme une pratique essentielle dans la gestion de projet informatique 35
Prendre en compte tout au long du projet l’aspect budgétaire pour une maîtrise des choix clés 38
Rationnaliser et durabiliser les infrastructures informatiques et les logiciels 39
Maîtriser l’évolution de l’architecture informatique 40
Rester à l’écoute et prévoir les risques pour renforcer la sécurisation 44
Contrôler les coûts de fonctionnement 45
CONCLUSION 45
BIBLIOGRAPHIE 47
ANNEXE 52

RESUME
Le domaine de l’informatique présente la particularité d’être l’objet d’innovations techniques de façon incessante afin d’améliorer ses performances et son évolutivité. Ces innovations ont raccourci la durée de vie des composants d’un projet informatique et technologique conduisant à l’obsolescence des technologies et logiciels utilisés d’une année à l’autre. Notre problématique est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Ainsi, le projet informatique a ses propres règles et exigences et se distingue par ses acteurs clés dont leur coopération garantit la réussite du projet. En plus, le gestionnaire du projet doit ainsi maîtriser le cycle de vie d’un produit du projet IT afin d’éviter l’obsolescence de ses composants. Cette obsolescence se présente sous diverses formes avec trois acteurs majeurs : fabricant, usager, autorités politiques. Afin de faire face à l’obsolescence, la maîtrise du risque aux différents stades du projet apparaît comme l’une des solutions les plus efficaces en tenant compte de divers facteurs. Le suivi de la réalisation du projet garantit sa pérennité en faisant une mise à jour régulière des composants du projet. Enfin, la gestion de l’obsolescence d’un projet IT requiert la mise en œuvre de quelques recommandations pour mieux le contrôler dans divers domaines (coûts, risques, …) tout en maîtrisant l’évolution de l’architecture informatique.
Mots clés : projet IT, obsolescence, cycle de vie produit, gestion
ABSTRACT
The computer field has the particularity of being the object of technical innovations in a ceaseless way in order to improve its performances and its evolutivity. These innovations have shortened the lifespan of the components of an IT and technological project, leading to the obsolescence of the technologies and software used from one year to the next. Our problem is to know how to achieve an optimal management of obsolescence risks in the framework of an IT project. Thus, the IT project has its own rules and requirements and is distinguished by its key players whose cooperation guarantees the success of the project. In addition, the project manager must control the life cycle of an IT project product in order to avoid the obsolescence of its components. This obsolescence comes in various forms with three major actors: manufacturer, user, political authorities. In order to face obsolescence, risk management at the different stages of the project appears to be one of the most efficient solutions taking into account various factors. Monitoring of the project’s implementation guarantees its durability by regularly updating the project’s components. Finally, the management of the obsolescence of an IT project requires the implementation of some recommendations to better control it in various fields (costs, risks, …) while controlling the evolution of the IT architecture.
Key words: IT project, obsolescence, product life cycle, management

INTRODUCTION

Dans tout projet, les risques liés au cycle de vie constituent une question pointeuse, car ils sont source de risques financiers ou encore tout simplement d’inefficacité d’un projet. Alors, imaginons cette situation dans le domaine de l’informatique qui présente la particularité d’être sans cesse l’objet d’innovations techniques qui conduisent à l’obsolescence des technologies et logiciels utilisés d’une année à l’autre. 
Cette innovation constante est pourtant à l’origine de beaucoup d’échecs de projets informatiques puisque les techniques et logiciels utilisés pour rechercher une solution informatique à un problème déterminé sont vite dépassés. Les chefs de projet ont la mauvaise pratique de vouloir une solution qui utilise les techniques récentes. Ils finissent par produire d’énormes dépenses dans l’innovation pour rattraper le retard technologique du projet, source d’une gabegie financière qui affecte gravement le projet. Parfois, cela conduit à un échec total, car le projet informatique mis en place ne répond plus à la problématique de base résolue par les technologies récentes.

La source du problème est cette absence de compréhension de la spécificité du cycle de projet informatique, mais aussi le manque de maître du cycle de vie des produits. 
Tout cela se traduit par ce qu’on appelle l’obsolescence qui frappe le projet informatique. L’obsolescence se présente de différentes façons dans un projet informatique. Il peut s’agir de langage informatique devenu obsolète avec le temps comme le cas du flash qui a été remplacé par le HTML5 rendant des sites internet totalement inaccessibles ou leur interface inutilisable. Pour de nombreuses entreprises, l’exemple de l’évolution du système d’exploitation de Windows fait office de cas d’école. Entre deux ou trois générations du système d’exploitation, vous avez aussi l’évolution de l’ensemble des matériaux qui l’accompagne telle que les processeurs, la carte graphique et bien d’autres. Pour pouvoir utiliser les fonctionnalités d’un nouveau système d’exploitation, l’ensemble du parc informatique de l’entreprise doit être renouvelé, ce qui constitue, au rythme très rapide d’obsolescence des logiciels et des ordinateurs, une dépense énorme.   
À cela s’ajoutent les problématiques de cybersécurité, car des techniques et logiciels obsolètes qui ne font plus l’objet de mises à jour sont des cibles faciles pour les pirates. Les failles ou les défaillances des systèmes affectent gravement l’efficacité et la pérennité du projet. Pourtant, acheter systématiquement les dernières versions des systèmes d’exploitation et les matériaux informatiques les plus récents représente un risque financier très lourd pour la viabilité du projet informatique.

Dans ce contexte, le rôle de la division ou de la direction informatique prend tout son sens puisque l’IT en général touche aux questions de sécurité informatique. Elle aborde aussi la gestion et la fourniture du matériel et les applications. Elle a une place importante aux côtés du chef de projet pour la maîtrise du projet informatique et la gestion du risque d’obsolescence. Il ne reste plus qu’à comprendre comment parvenir à cette gestion des risques d’obsolescence.
Ainsi, notre problématique est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT ?
Pour y répondre, nous allons d’abord voir les concepts et les études sur l’implication de l’obsolescence dans la gestion d’un projet informatique et technologique (partie I), puis les recherches et analyses empiriques (partie II) dans le souci d’avoir une vision pratique propre à dégager des solutions réalistes et faisables.

Partie I : LES CONCEPTS ET LES ETUDES SUR L’IMPLICATION DE L’OBSOLESCENCE DANS LA GESTION D’UN PROJET INFORMATIQUE ET TECHNOLOGIQUE

Chapitre I APPLICATION DE LA GESTION DANS LA CONDUITE D’UN PROJET INFORMATIQUE ET TECHNOLOGIQUE
a) La gestion de projet sous le prisme de l’informatique et la technologie
Si on se réfère au schéma classique de la gestion de projet nous nous arrêterions à un cycle de projet classique avec au début l’élaboration d’une feuille de route, d’un plan d’action ou d’un cahier des charges. En effet, le projet classique est orienté sur la planification en début de projet pour se conclure sur l’évaluation. Donc les ressources matériels, humaines et financières sont plus ou moins fixe au début du projet et ne changerons qu’à la toute fin. Il en est de même des objectifs et sous objectifs.
Cela a l’avantage de nous permettre une bonne préparation pour combattre l’ensemble des risques d’un projet classique. Par exemple, Il s’agit des risques liés à la gestion budgétaire (budget prévisionnel). Cependant, cette méthode a pour défaut de ne pas prendre en compte les facteurs liés aux développements technologiques. Cette démarche n’est donc pas suffisamment encrée dans le réel pour permettre une prise en compte des caractéristiques spécifique du projet informatique. En pratique, la tendance était de faire un plan Informatique Annuel. Cette solution n’envisage pas le projet informatique comme étant différent des autres. Elle cherche à adapter les règles classiques du projet au cas du projet informatique.
Le plan informatique annuel détermine le budget, la version dans laquelle faire arriver le projet, et par conséquent le délai et le contenu à délivrer. Toutefois, elle ne donne qu’une estimation vague, parfois erronée, de la charge de travail et du budget qui en découle. Le chef de projet tombe inévitablement dans le dépassement budgétaire ou la réduction du périmètre fonctionnel. Le modèle est beaucoup trop rigide et s’adapte mal à l’évolution technologique.
Cette méthode sépare aussi le manager et le technicien sans prendre en compte que la coopération et la communication permanant entre les deux est un facteur important de la réussite du projet. Surtout dans le cas de l’obsolescence que nous cherchons à résoudre cette absence de communication peut conduire le manager (rêveur optimiste) à entrer en conflit ou ne pas communiquer avec le technicien (trop réaliste, parfois pessimiste). Voilà pourquoi certain projet peut très vite devenir un échec aussi bien au niveau de l’atteinte des objectifs que dans la gestion du budget.
Il est vrai que pour des projets de petite envergure le plan informatique annuel peut être utile, car même en cas de dépassement budgétaire il ne présente pas de risque particulièrement important pour la viabilité et la réussite du projet. Dans un projet qui présente un budget plus important le possible dépassement budgétaire induit par l’évolution technologique, les bugs et les risques de piratage peuvent conduire à la ruine et au discrédit de l’entreprise. Il en est ainsi d’un projet qui utilisé un software déjà dépassé ou un codage qui devient obsolète d’une année à l’autre remettant en cause l’intégralité du projet. Ou encore de l’obsolescence du matériel informatique qui ne fonctionne pas avec le dernier logiciel. Alors que l’utilisation du dit logiciel permet de gagner un temps fou pour la réalisation des tâches ce qui induit également une réduction du coût du projet.
Voilà pourquoi le projet informatique doit être considéré comme une forme de projet à part entière qui obéit à ses propres règles et exigences. Ainsi, la maîtrise de la conduite de projet informatique nécessite de connaître clairement ce que l’on peut attendre comme finalité et les éventuelles évolutions à prendre en compte, de contrôler le budget (début, pendant et à la fin) et répondre aux exigences du client.
b) Cycle de projet dans le contexte informatique
Nous avons vu que les exigences et les méthodes classiques de la gestion de projet doivent être modifié pour un projet informatique. Cela affecte tout particulièrement le cycle de projet. Dans le projet classique nous partons de l’idée ou de la vision qui donne naissance au projet. Un idéal à atteindre qui guide la démarche de l’équipe tout au long du projet. On procède à l’instruction et la planification du projet. A ce stade du projet l’on détermine les opportunités ou menace éventuel.
La réalisation du projet et la planification opérationnelle aboutie à l’allocation des ressources humaines, matériel et financière.
Le projet se conclut par la phase d’exploitation et son évaluation pour procéder aux éventuelles rectifications.
Pour un projet informatique, le schéma du cycle de vie différent concernant l’avant, pendant et après le projet. Si l’on prend le modèle classique auquel s’intègre normalement un plan informatique annuel, on peut remarquer qu’après avoir testé le projet l’on doit encore perdre des ressources dans l’intégration de celui-ci.
Dans un modèle qui prend le projet informatique dans sa globalité l’on doit prendre en compte les opportunités constantes de l’informatique et des nouvelles technologies, sans négliger le budget pour le financer, par des études menées pour la préparation du projet. On obtient une image détaillée des contraintes du projet et lors de la mise en œuvre, les études entreprises seront prises en compte pour la mise en place et la stabilisation de celui-ci. L’activité de la conduite d’un projet informatique peut se résumer en trois principales actions formant un cycle : analyser, organiser, produire et piloter (YENDE R.G., 2019)
Ainsi, la structure intègre les exigences pour valider le projet et un contrôle adapté à sa pérennité tout au long du projet plutôt que de l’envisager en fin de parcours. Elle permet une meilleure compréhension du besoin. Cela est essentiel à la réussite du projet.
c) Acteur clé
Le projet informatique se distingue aussi par ses acteurs clés qui différent d’un projet normal et dans l’implication dans le projet ou la coopération est essentiel à la réussite du projet. Dans un schéma classique nous pouvons avoir d’un côté le manager et de l’autre les techniciens. Le manager est à la manœuvre quand le technicien n’est pour l’essentiel qu’un exécutant qui donne forme aux attentes du manager.
Dans un projet informatique, l’absence de communication et de compréhension entre les deux acteurs représente le plus grand facteur d’échec du projet. L’on verra un peu plus tard que cela a aussi un impact en ce qui concerne l’obsolescence.
Le technicien informatique n’est pas qu’un simple exécutant. Il doit maîtriser la plus grande partie du projet. Le manager ou client a la vision et les grandes lignes du projet, mais le technicien est le seul à savoir comment y parvenir et si celui est réaliste au point de vue budgétaire ou technologique. La communication entre les deux acteurs est donc plus importante que dans un projet normal. Le client assure la fonction de donneur d’ordre alors que le technicien informatique assure la fonction de maître d’œuvre. Au milieu intervient un autre acteur, le maître d’ouvrage qui regroupe les intermédiaires entre le technicien informatique et le client. Toutefois, si une communication continue entre les différents acteurs est importante il faut que chacun respecte sa sphère de compétence.
Le client donneur d’ordre présente les besoins, mais il ne peut formuler d’une manière correcte ses derniers. L’informaticien peut donc se retrouver à réaliser le projet sous une forme alors que le client avait une tout autre attente. Le maître d’ouvrage intervient pour faire correspondre les deux. Ce dernier a souvent la double maîtrise (management et informatique) ou une bonne maîtrise du management avec suffisamment de compétence en informatique pour ne pas être dépassé par le langage technique. Il devient le point clé de la relation, car le client, l’informaticien et l’utilisateur final communiqueront avec lui pour conduire le projet.
Cet acteur clé doit comprendre l’environnement informatique ; en particulier les évolutions constantes et leur impact par rapport au projet. Il pourra intervenir dans les décisions importantes comme le choix d’opérer un virage technologique. Il peut évaluer la faisabilité du changement avec le technicien et l’opportunité de celui-ci avec le client.
d) Le cycle de vie des produits dans un projet informatique
Le produit final ou l’ouvrage est un ensemble de produits qui travaillent ensemble. Il constitue le résultat du projet. Il peut se présenter sous forme d’équipement ou d’ouvrage matériel à réaliser ou de création d’un service.
Le produit naît avec l’expression des besoins dans son aspect fonctionnel. Il suit une analyse de fonctionnel se traduisant par la réalisation d’un cahier des charges. Il est accompagné par une définition spécifique et technique des besoins pour caractériser au point de vue technique le produit. Le produit s’inscrit alors comme une composante d’un système ou d’un sous-système.
Une fois conçu, il est testé et transformé. Elle prend en compte les évolutions. Pour un projet informatique, la maîtrise du cycle de vie des projets est essentielle. Il s’agit d’un des facteurs à l’origine de l’obsolescence puisque le gestionnaire de projet a, dans la majorité des cas, une mauvaise maîtrise du cycle de vie des produits (PINEL, 2013) . Il peut s’agir des composantes informatiques qui compose le produit final et qui très vite deviennent obsolète (mauvaise veille technologique) ou au contraire d’un produit qui est encore utile alors que de nouvelle technologie commence à apparaitre. La maîtrise du cycle de vie des produits permet d’envisager l’obsolescence sous un angle nouveau.
Chapitre II : L’OBSOLESCENCE AU CŒUR DU CYCLE DE PROJET INFORMATIQUE ET TECHNOLOGIQUE
Dans une organisation, l’obsolescence doit être évaluée pour de multiples raisons dont :

les raisons budgétaires pour pouvoir faire une prévision du budget à court ou à long terme en ayant une vision sur les matériels, les systèmes ou les migrations à prévoir.
la réponse aux besoins des utilisateurs : les travailleurs ont besoin de services de qualité en termes de performance et d’usage
la sécurité de l’entreprise : les responsables doivent maîtriser totalement le fonctionnement de toutes les machines utilisées au sein de l’entreprise. Même un manque de mises à jour peut être défaillant pour la productivité de la société.
la prévention des éventuels changements organisationnels : au fur et à mesure que l’entreprise se développe, elle doit s’assurer que toutes les machines notamment les serveurs peuvent accueillir et supporter toute croissance en vue. Les infrastructures mises en œuvre doivent avoir la capacité de confronter à divers changements.
En maîtrisant le cycle de vie (Figure 1) d’un projet informatique et technologique, il est possible de prévoir et envisager l’obsolescence pouvant l’affecter. D’ailleurs, un tel projet peut se placer à la conjonction des paramètres techniques et humains (BOUTINET J.P., 2012). En faisant l’analyse de l’obsolescence dans le cycle de vie, cela peut servir de prédiction suivant les motivations définies par les experts. Dans ce cas, il importe de répondre à quelques questions importantes du point de vue économique et d’intérêt fonctionnel comme :
• Est-ce encore une fonction utile ?
• Son coût de réparation ou de remédiation correspond-il a besoin ou à l’usage ?
• S’agit-il d’une fonction principale, sécuritaire ou accessoire ? (BOISSIE K. ; 2019).

Fig.1 : Cycle de vie d’un élément (BOISSIE K., 2019)
Si l’on simplifie ce schéma du cycle de vie d’un élément ou d’un produit, on obtient la courbe suivante :

Fig.2 : Modèle d’une courbe de cycle de vie d’un projet
a) Les formes de l’obsolescence qui affectent le projet
De nos jours, le système d’information est intégré dans un projet informatique et technologique d’une entreprise. Etant le nerf central de l’entreprise, il représente son levier stratégique par sa transversalité avec tous les métiers organisationnels (PILNARD M, 2015). Dans ce domaine, le sujet de l’obsolescence du système d’information est peu abordé qu’il devient difficile de discuter de sa maturité, et donc de la gérer. Ce problème d’obsolescence est souvent décrété par le marché, le fournisseur ou l’éditeur (PILNARD M, 2015). Même si l’obsolescence du système d’information est peu traitée dans différents ouvrages, l’obsolescence en elle-même est valable dans tous les domaines (produits, bâtiments, management, …). Obsolescence vient du mot latin obsolescere qui signifie « perdre de la valeur », et un élément est dit obsolète lorsqu’on arrête sa fabrication suite à une chute de la demande, ou lorsque les matériaux utiles pour sa fabrication ne sont plus disponibles (SANDBORN, 2007). Dans le domaine du système d’information, le phénomène d’obsolescence est présent lorsqu’ « une infrastructure, c’est-à-dire l’ensemble des équipements nécessaires au bon fonctionnement du système d’information des entreprises (du hardware au software), n’est plus proposée à la vente et que l’éditeur ou le constructeur n’en assure plus le support » (AHOUANDJINOU, 2015).
Il importe de préciser que c’est l’obsolescence telle qu’elle qui n’est pas citée dans différents ouvrages, mais l’obsolescence programmée est bien citée dans nombreux ouvrages et bien étudiée à de nombreuses reprises (ROLLOT M, 2016) . Ce terme d’obsolescence programmée a été déjà soulévée en 1932 par Bernard London lorsqu’il expliquait que « le peuple américain ne continuait pas à utiliser chaque chose jusqu’à avoir totalement épuisé ses capacités. Ils remplaçaient les vieux objets par des neufs du fait de la mode ou de leur modernité. (…) se souciant à peine de savoir si elles étaient obsolètes ».
Ensuite, en 1955, le vice-président de General Motors, Harley J. Earl disait « le travail principal était de hâter l’obsolescence. En 1934, le changement de voiture se faisait tous les cinq ans en moyenne. Maintenant, c’est tous les deux ans ». Donc, l’obsolescence programmée peut être définie comme étant « une somme de techniques industrielles et commerciales visant à un seul but : entretenir le cycle de consommation afin de faire tourner les usines et les flux de marchandises. Pour ce faire, le plus simple reste encore de réduire le cycle de vie ». (LAPOIX, 2011).
Enfin, l’ADEME définit cette obsolescence programmée comme étant un « stratagème par lequel un bien verrait sa durée normative réduite dès sa conception, limitant ainsi sa durée d’usage pour des raisons économiques » et aussi comme une « pratique déloyale envers les consommateurs, avec des effets environnementaux importants, affectant négativement la balance commerciale de la France ».
Ainsi, l’obsolescence peut être définie comme la perte de valeur d’un produit au fur et à mesure qu’il avance dans son cycle de vie. Et l’obsolescence programmée est le fait de limiter la durée de vie d’un produit de manière intentionnelle (SAUVAGE S. et VASSEUR L., 2017) . Même s’il existe plus d’une dizaine de types d’obsolescence, nous retiendrons uniquement ceux qui ont une réelle signification dans le domaine des systèmes d’information. Ainsi, il en existe deux classifications de l’obsolescence : l’obsolescence fonctionnelle et l’obsolescence psychologique (PILNARD M, 2015)

Fig.3 : Typologie de l’obsolescence dans le domaine des systèmes d’information (PILNARD M, 2015)
L’obsolescence fonctionnelle
Elle a un impact sur la vision de l’entreprise, car elle détermine les écarts entre les fonctionnalités d’une application et les besoins des utilisateurs. Tel est le cas lorsqu’elle n’assure pas ou ne fait plus sa fonction pour des problèmes technologiques ou conjoncturels.
Dans la branche technologique, différents facteurs réduisent la durabilité d’un produit, d’où :
• l’obsolescence par indisponibilité, lorsque le produit n’est plus fabriqué
• l’obsolescence par notification, lorsque le produit présente un souci et avertit l’utilisateur tel qu’une imprimante avec cartouche obsolète ou manque d’encre, …
• l’obsolescence indirecte à cause d’un défaut interne qui affecte le produit pour qu’il ne puisse plus fonctionner.
• l’obsolescence par incompatibilité lorsque le produit a besoin d’un mis à jour pour qu’il puisse fonctionner normalement, voire de façon optimale. Il est nécessaire de changer les appareils anciens modèles avec des nouveaux modèles ou les anciennes versions d’une application par la dernière version .
La branche conjoncturelle est formée surtout par les éléments politiques, légaux et économiques. Ainsi, dans cette branche, il y a :
• l’obsolescence économique déclenchée par l’augmentation du coût des stocks et des pièces de rechange
• l’obsolescence réglementaire engendrée par l’évolution des exigences légales sur la technologie, les règles financières et la sécurité. Les ERP doivent être mises aux normes financières, rendant un outil obsolète par l’évolution de ces normes (PILNARD M, 2015).
L’obsolescence psychologique
C’est une obsolescence ayant un impact sur les consommateurs qui sont habitués à suivre l’évolution du marché par le biais de la publicité et de la stratégie marketing des entreprises. De ce fait, il y a :
• l’obsolescence esthétique et ergonomique qui est basée sur l’effet de mode conduisant à une consommation de masse due au design du produit
• l’obsolescence commerciale due à un large choix de consommation face aux nombreuses offres que proposent les différents concurrents.
Ce qu’il faut préciser, c’est que l’impact de chaque obsolescence n’est pas le même sur la vie d’une entreprise. Dans une organisation, l’obsolescence fonctionnelle aura plus d’intérêt par rapport à l’obsolescence psychologique (LIBAERT T., 2015), parce qu’elle comporte des aspects incontournables concernant l’importance du rôle du fabricant dans sa décision (PILNARD M, 2015).
Les acteurs de l’obsolescence d’un projet IT
Lors du lancement du processus d’obsolescence d’un projet IT, il y a toujours deux acteurs majeurs qui sont l’éditeur et les consommateurs (les entreprises).
L’éditeur est formé par le concepteur d’applications et de logiciels. Il doit proposer au fil du temps un produit plus performant par rapport aux autres concurrences. Plus la technologie évolue, plus les entreprises ont besoin d’un produit qui se démarque des opposants. Il a un rôle important dans le processus de décision de l’obsolescence d’un produit. C’est lui qui décide s’il souhaite perdurer ou non sur le marché, il n’a qu’à faire un renouvellement incessant et rendre ses propres produits obsolètes. Par conséquent, l’obsolescence devient inévitable lorsque l’éditeur décide d’arrêter la maintenance ou la production de certains outils (PILNARD M, 2015).
Quant aux consommateurs, eux aussi a le pouvoir de décider de l’obsolescence d’un produit si personne ne peut gérer la problématique affectant un produit. Effectivement, le phénomène de l’obsolescence touchera le domaine du système d’information si l’entreprise ne prend pas en considération l’utilité de la gestion de l’obsolescence (CIGREF, 2003). Par sa transversalité, ce problème d’obsolescence doit être principalement sous la responsabilité des directions du système d’information (BOHNKE, 2010) en surveillant les risques tout en les anticipant. C’est cette direction qui qui doit communiquer les composants du système d’information de l’entreprise, sa maintenance, son obsolescence, et notamment ses alternatives. En outre, la direction générale de l’entreprise a aussi son rôle dans la prise de décision de l’obsolescence d’un outil pouvant avoir un impact sur la vie de l’entreprise. C’est une décision qui ne doit pas être prise à la légère, elle doit être bien construite, argumentée et accompagnée (PILNARD M, 2015).
b) Entre gestion d’un risque financier et technique face à l’obsolescence
Face l’obsolescence d’un projet IT, les dirigeants ont tendance à diminuer les coûts alors que son exploitation et sa maintenance ont un coût beaucoup plus élevé qu’il devient plus difficile de s’y investir ultérieurement (BOHNKE, 2010). Cela nécessite une analyse régulière de la balance entre les coûts d’un renouvellement d’un produit incluant sa maintenance et les coûts de production où il y a l’étude, l’exécution, l’achat, et l’impact d’un décommissioning (AHOUANDJINOU, 2015). En optant pour la maintenance, il faut savoir que son coût vaut 67 % du coût total de la durée de vie d’un système d’information, et 48% de ce coût de maintenance servent à corriger et à réparer les anomalies constatées. Ce qui veut dire qu’un système d’information a une durée de vie appelée délai ayant un impact majeur sur son coût (PILNARD M, 2015). En s’intéressant au coût total de possession (TCO), le cycle de vie d’un système d’information peut avoir les coûts suivants (PERCIE du SERT, 2012) :

coûts d’acquisition : licence ou développement
coûts de détention ou d’exploitation : utilisation et maintenance
coûts de démantèlement ou retrait de service
coûts de pénalité
Ces coûts peuvent être considérer sous une vision sur double coût (BOHNKE, 2010) :
coûts directs : matériel, logiciel, …
coûts indirects ou coûts cachés : maintenance, formation, administration, évolution, ….
En général, ces différents coûts poussent souvent l’entreprise à passer à la recherche d’un nouvel outil. En effet, le coût de maintenance a parfois tendance à croître incessamment qu’il dépasse même le coût d’un nouvel outil. C’est pourquoi l’entreprise opte pour le remplacement indiquant la relation entre la gestion du risque financier et la technique à adopter face à l’obsolescence.
c) Le risque pour l’image et la pérennité du projet
Un projet IT « comporte intrinsèquement un risque déterminé par la stratégie, la technologie, le contexte, ou encore le périmètre du projet » (AZAN W & MILOUD T., 2019), affectant son image et sa pérennité. Ce qui signifie qu’un risque est dit important s’il intègre un projet avec une complexité de périmètre, un grand nombre d’acteurs, une technologie peu maîtrisée et un contexte organisationnel difficile. Afin d’évaluer les risques intrinsèques d’un projet IT, il importe de déterminer la probabilité d’occurrences du risque et les pertes associées sur le projet au risque. Chacun d’entre ces paramètres doivent être isolé et traité de manière analytique pour diminuer l’exposition aux risques dans le cadre d’une gestion de risques (AZAN W & MILOUD T., 2019).
Ainsi, dans un projet IT, il existe cinq types de risques qui peuvent être recensés :
le risque stratégique : première dérive de la durée du retour sur investissement du projet (GEFEN, 2004) associé à une anticipation insuffisante de la réaction des clients et employés, à une évolution brutale de la concurrence, à un choix technologique inadapté, à une incertitude stratégique, à une implication insuffisante de la direction générale dans la maîtrise du projet (BESSON, 1999).
le risque lié à l’utilisateur se manifeste par des usages détournés (AZAN & BELDI, 2009) ou par la mauvaise utilisation du système (De VAUJANY, 2007a ; 2007b ; KALLINIKOS, 2004). Ce qui pourrait causer ce type de risque est la défaillance de la communication, de la concertation, de l’implication et de la formation (AZAN W & MILOUD T., 2019).
le risque de la dérive technologique en faisant appel à une technologie émergente au lieu d’une technologie éprouvée. Ce type de risque consiste au phasage des travaux, charge et complexité du pilotage de ressources pluridisciplinaires en les sous-estimant. Ce qui entraîne fréquemment un dimensionnement insuffisant de l’organisation et des ressources du projet. Tout cela aura un impact durable sur son fonctionnement, et donc son image et sa pérennité et dont le scénario le plus grave est la défaillance de l’éditeur (AUBERT ET AL., 2004).
le risque lié au client du projet IT qui peut s’objectiver dans la reconduction tacite des principes et des règles du système existant (BESSON, 1999). Il résulte d’une mauvaise prise en compte des contraintes spécifiques du client comme les règles de confidentialité et de protection des données des clients dans le domaine bancaire (AZAN W & MILOUD T., 2019).
le risque relatif à la solution technologique, concernant les ERP. Plusieurs risques sont associés aux solutions techniques et technologiques, dont on peut trouver une variété de typologie de risque (ROSS et al., 2002),
d) Le risque de sécurité
Investir dans l’utilisation d’une technologie de pointe permet de réaliser des économies tout en favorisant l’amélioration des performances techniques souhaitées du système. Une approche fondée sur la théorie des options réelles est utilisée dans la pratique pour valoriser les risques de projet d’ERP. AMRAM et KULATILAKA (2000) ont développé une approche qui considère les projets ERP comme une source de valeur parmi d’autres. Il est nécessaire de les arbitrer selon les évolutions futures et actuelles ainsi que les gains de flexibilité procurés à l’entreprise grâce au progiciel. Ces gains de flexibilité ont un caractère souvent transversal, et ils comportent des risques de sécurité tout à fait spécifiques qu’il nous faut détailler :
premier risque : c’est une démarche qui consiste à mettre en place des solutions en faisant l’analyse et l’évaluation des différents scénarios possibles. Elle ne correspond pas souvent à la problématique à traiter et ne permet pas de s’assurer de la pertinence de la solution retenue.
deuxième risque : caractérisé par une structuration insuffisante du projet et une méconnaissance des facteurs de complexité (nombre élevé de composants, d’intervenants, d’entités et de sites concernés) ayant un impact conséquent sur la durée des travaux.
troisième risque : une mauvaise anticipation des modifications des comportements collectifs. Dans ce cas, l’utilisation du nouvel IT dépasse les prévisions entraînant une dégradation des performances. Ce qui mène à des perturbations significatives dans le fonctionnement de l’entreprise caractérisées par une incertitude technologique et une incertitude stratégique (Annexe II).

Partie II : RECHERCHE ET ANALYSE EMPIRIQUE
Chapitre I : MAITRISE DU RISQUE D’OBSOLESCENCE AUX DIFFERENTS STADES DU PROJET
a) Contrôle avant-projet : état des lieux des technologies existantes et futures
Après avoir défini l’obsolescence dans son ensemble, il est de notre intérêt d’étudier l’état des lieux des technologies existantes et futures. Cela nous permet de gérer de façon la plus efficace possible l’obsolescence d’un projet informatique et technologique (IT). Cette étude va nous mener vers une décision suite à de nombreuses réflexions qui auront des répercussions importantes sur la vie d’une entreprise. Pour cela, il importe d’étudier les différents facteurs qui pourraient être considérés pour la prise de décision sur la migration ou non des données d’un outil du projet après avoir identifié son obsolescence.
Ce contrôle avant-projet permet aux entreprises de forcer l’obsolescence si cela leur conduit à une évolution en passant par l’étape de la migration, mais dans les meilleures conditions. L’état des lieux des technologies existantes et futures sera étudié en trois sous-parties en prenant en compte tous les acteurs du projet au sein d’une entreprise. D’ailleurs, comme on parle d’obsolescence d’un projet IT, la décision à prendre est un peu compliqué.
Un projet IT performant
Pour pouvoir dire qu’un projet est obsolète, il faut d’abord connaître ce qui décrit sa performance. Ainsi, un projet IT performant doit être en adéquation avec la stratégie de l’entreprise ainsi qu’avec les objectifs de ses activités. Il est conforme avec les obligations légales et respecte le plan d’urbanisme. Un projet IT est dit performant lorsqu’il est facile à utiliser, sécurisé, fiable, adaptatif, efficient, disponible et pérenne . En outre, un projet IT performant doit avoir une forte implication de la direction dans sa gestion qui doit superviser la mise en place des outils du pilotage (SDI, documents mis à jour de la gouvernance du projet IT, des tableaux de bord de suivi de l’informatique, etc.). Il doit avoir une politique de sécurité validée et soutenue par la direction de l’entité en respectant la législation en matière d’informatique et technologique (IT). Un tel projet doit être conçu dans le respect des bonnes pratiques de commande publique avec un paramétrage correct des droits d’accès aux applications informatiques. Le plus important est qu’un projet IT doit être performant grâce à une bonne gestion de son développement caractérisée par l’implication de la direction générale, une vision claire des objectifs et des résultats attendus avec des responsabilités bien définies pour chaque prenante. Ce qui signifie qu’il nécessite l’implication complète des bureaux de métiers et des cadres expérimentés . Bref, un projet IT performant s’accompagne toujours de choix techniques pérennes et d’une gestion rigoureuse pour garantir un déploiement échelonné menant à un changement efficace.
Les facteurs humains
L’obsolescence d’un projet IT est ainsi dû à plusieurs facteurs humains qui se résume sur trois éléments majeurs : la résistance au changement, la théorie de millefeuille et l’acceptation de la technologie.
La résistance au changement est comme un caractère commun à tous les humains parce qu’un changement signifie « une altération de la réalité dans laquelle évolue une personne. Il altère ses certitudes et ses projections dans l’avenir » (CARTON, 2011). Alors, la résistance au changement est un phénomène, considéré comme naturel, qui tente de se préserver ou s’opposer, par aversion à l’incertitude, face à une nouvelle proposition susceptible de modifier l’environnement existant (PILNARD M., 2015). Et dans un projet IT, il s’agit plutôt de projets socio-technico-économiques et pas de projets spécifiques à un domaine précis (KAMINSKI, 2015). Et ce qu’il est de l’obsolescence, il faut faire une formation et une communication pour accompagner le changement en identifiant clairement l’existant et le futur (THEVENOT, 2015) (Annexe III). Ainsi, le changement sera mieux conduit pour que son impact soit moins violent. Dans le cas où l’on constate une forte résistance au changement après avoir changé un outil du système d’information, il importe d’inclure les collaborateurs et leur donner des formations appropriées aux différents outils.
D’après la théorie du millefeuille (KALIKA, 2007), les différents moyens de communication dans un projet IT sont juxtaposés comme des multiples couches de millefeuille. Or, chaque outil a ses qualités et se défauts que les uns des autres ne peuvent pas se substituer. Et les entreprises tendent à avoir des difficultés pour établir l’existant et l’organiser formant une architecture peu solide involontairement. Ce qui donne naissance à une nouvelle application diminuant la valeur du système d’information (BOHNKE, 2010). Ainsi, si la décision de la direction générale de l’entreprise est d’opter pour le changement du système d’information, il est important de veiller à une meilleure organisation des strates applicatives (PILNARD M., 2015).
Pour pouvoir apporter des modifications à un système d’information et pour qu’il soit mieux accepté par les collaborateurs, il importe de les prédire. En fait, l’acceptation technologique est déterminée par des variables relevant de la perception et des attitudes :
• L’utilité perçue (UP) qui indique le degré auquel une personne reconnaît l’importance d’un système dans ses performances. Ce qui crée en-elle l’intention de l’utiliser, les attitudes (A) ;
• La facilité d’utilisation perçue (FUP) lui montrant que plus le système est modifié, plus son utilisation sera dénuée d’efforts (DAVIS, 1986).

Fig.4 : Modèle d’acceptation des technologies (Davis, 1986)
Ce modèle d’acceptation des technologies ou TAM (Technology Acceptance Model) a été proposé par Davis dans sa thèse de Doctorat en 1986, puis repris par lui-même et ses compagnies en 1989 (DAVIS, 1989 ; DAVIS, BAGOZZI & WARSHAW, 1989). Il s’agit du modèle dominant de l’acceptabilité et de l’adoption des technologies de l’information et de la communication (TIC) (HSIAO & YANG, 2011).
Dans le contexte de l’obsolescence, la question qui se pose est de savoir si un individu est prêt à se confronter à d’éventuels changements ou non. Mais, en général, pour pallier l’obsolescence d’un outil informatique, la perception globale de l’individu par rapport au nouvel outil mis en place doit être prise en compte (PILNARD M, 2015).
Les facteurs technologiques
Pour contrôler la maîtrise du risque de l’obsolescence d’un projet IT, la période avant-projet doit faire état des lieux technologiques existant et futurs en tenant compte des facteurs technologiques. En fait, en termes technologiques, les facteurs induisant l’obsolescence d’un projet IT sont :
• Les bugs et dysfonctionnements : caractérisés par des problèmes mineurs perçus comme n’ayant pas de répercussions jusqu’à des incidents majeurs accompagnés des dégâts importants incluant la perte d’information (CIGREF, 2003). Ainsi, les risques de dysfonctionnements dus à l’obsolescence et une architecture du système non adaptée doivent être considérer dès le début du projet, ainsi que la fiabilité de l’outil (PILNARD M, 2015).
• Les outils de remplacement doivent également être identifiés dès le début parce qu’aucun changement ne doit être envisagé si l’on ne sait pas encore vers quoi se diriger dans le futur. La prise en compte de ce facteur de remplacement technologique est importante afin d’éviter de perdre des données ou des fonctionnalités habituelles.
• La rationalisation sachant que l’accumulation d’applications et de logiciels est à l’origine des redondances et des doublons alors que certains d’entre eux ne sont plus utilisés. Par la rationalisation, le principe est simple, il ne faut garder que les outils ayant une réelle valeur ajoutée au projet.
En effet, pour pouvoir remédier aux causes de l’obsolescence, il faut s’orienter sur trois axes :

un usage long, en termes de durabilité, pour un produit qui n’est pas encore conçu ;
un usage étendu en essayant de prolonger la durée de vie d’un élément d’un outil technologique ayant démarré son cycle de vie ;
un état de rétablissement ou de reprise d’un outil informatique éteint ou en fin de cycle de vie (BOISSIE K., 2019)
Les facteurs organisationnels
Dans un projet IT, pour pouvoir maîtriser le risque d’obsolescence, il faut aussi prendre en compte de deux facteurs organisationnels : la balance des coûts et l’agilité de l’entreprise.
Comme il a été soulevé précédemment, il arrive souvent que le coût de maintenance soit plus élevé que le coût d’un nouvel achat ou d’une nouvelle licence. Ainsi, dès qu’une obsolescence ne serait-ce qu’une partie du projet est constaté, il est préférable d’y remédier par l’achat d’une nouvelle licence. S’il s’agit d’un tout nouvel outil, il faut ajouter au coût de licence les coûts de migration de données.
L’agilité de l’entreprise concerne son « adaptation au quotidien en mobilisant l’intelligence collective pour atteindre ses objectifs » (KEROMEN, 2014). Ce qui permet à cette entreprise d’agir en mode itératif, incrémental tout en faisant preuve de réactivité et de flexibilité (PILNARD M, 2015).
Donc, face à l’obsolescence d’un projet, il importe de voir les facteurs humains, technologiques et organisationnels au sein de l’entreprise pour pouvoir la maîtriser. La prise en compte de ces trois facteurs permet d’évaluer la performance pour voir s’il faut recourir à un changement de système d’information ou non. Si l’impact est négatif, l’entreprise doit penser à changer uniquement l’outil obsolète pour avoir un meilleur niveau de performance (PILNARD M, 2015). En fait, l’identification d’une obsolescence dans une partie du projet IT doit conduire à la prise en compte de certains facteurs pour aider à la décision de changer d’outil ou non. Ce qui signifie probablement la migration des données sur un nouvel outil ou le choix de rester sur la plateforme existante.
b) Suivi dans la phase de construction et réalisation du projet
La nature des relations usager/objet est influencé par les diverses formes d’obsolescence : planifiées, technologiques, psychologiques et économiques (DEMENE C & MARCHAND A., 2015). Cette obsolescence est marquée notamment par la diminution de la durée de vie des produits informatiques et technologiques. La responsabilité principale de cette obsolescence revient au fabricant et l’usager, que ce soit un particulier ou une entreprise, demeure la victime. D’ailleurs, les éléments utilisés dans un projet IT évoluent avec un rythme différent : parfois, il s’accélère, ou se ralentit, et parfois, il reste relativement stable, rendant plus compliqué la gestion de l’obsolescence (PILNARD M, 2015).
Dans la phase de construction et réalisation d’un projet IT, il est important de considérer la dette et l’obsolescence IT qui augmentent de plus en plus au sein de l’entreprise. Elles tendent à devenir un enjeu stratégique pour les DSI (direction des systèmes d’information) dans le contexte. La dette IT indique l’écart entre l’existant et la cible ayant pour vocation à être corrigée et résorbée via divers travaux. Cet écart concerne notamment l’état de l’art des composants du SI visé par l’entreprise (code, logiciel, infrastructure, compétences, matériels informatiques, …) (CIGREF, 2021). Quant à l’obsolescence IT, à l’inverse de la dette IT, elle a vocation à être entièrement décommissionnée ou réécrite via des fonctionnalités réécrites à l’état de l’art dans d’autres composants . Cette obsolescence IT donne souvent une vision d’ancienneté qui peut être complexe et liée aux évolutions techniques.
La dette IT
La dette IT, un enjeu stratégique pour les DSI
Parler de « dette » rime avec une dimension financière. Dans le cadre d’un projet IT, il s’agit d’un terme inventé par Ward Cunningham en 1992, appliqué au domaine du développement logiciel. C’est une métaphore inspirée du concept de la dette dans le domaine des finances et entreprises. C’est une forme d’obsolescence liée au vieillissement du système d’information indiquant une conséquence d’écarts avec différentes exigences. Un jour, l’entreprise doit faire face à la montée de la base de données d’une version qui est devenue obsolète ou remplacer un composant contenant des failles de sécurité, bien connues par tous les collaborateurs.
Par conséquent, la dette IT est donc un enjeu de plus en plus stratégique pour les DSI qui doit être bien reconnue pour mieux l’admettre et non pas la cacher ou en rejeter l’idée. Elle doit être traitée et gérée au quotidien en cloisonnant les systèmes pour pouvoir les faire évoluer séparément, et ensuite, les décloisonner en utilisant des interfaces modernes. Effectivement, sous les poids de dettes de développement non remboursées, une DSI peut être bloquée. Lorsqu’une dette n’est pas remboursée rapidement, elle représente un danger ajouté aux intérêts dus parce que les développeurs doivent les rembourser à chaque fois qu’ils passent un code pas tout à fait exact, ils doivent les rembourser tôt ou tard.
Réduire la dette IT en la maîtrisant
Pour pouvoir réduire la dette IT, il importe de connaître d’abord les grandes catégories de dettes techniques dont :
• La dette accumulée au fil du temps due aux changements ou aux évolutions de framework de développement : si aucun suivi n’est effectué sur l’amélioration du framework utilisé, il devient difficile d’adopter les versions plus récentes. Mais c’est la catégorie de la dette IT la moins destructrice et la plus facile à maîtriser parce qu’elle se rembourse par l’adoption d’une bonne stratégie de mise à jour du framework.
• La dette liée aux obsolescences de certaines parties du code pour des projets qui dépendent d’éléments externes (API, modèles, architecture, …). Elle nécessite la création de mise à jour, car elle est inévitable dans le développement logiciel et peut perdurer tout au long de la vie du produit.
• La dette pragmatique : afin de tenir les délais et le budget, il n’y a jamais assez de temps pour réaliser un travail parfait pour un développement logiciel, en acceptant un compromis sur la qualité.
Pour réduire la dette IT, le processus de sa gestion doit gagner en maturité en réalisant un travail de recensement et d’évaluation pour être efficace. Mais c’est un travail difficile et complexe à cause de la complexité des systèmes, et aussi les cartographies incomplètes, la multiplicité des fournisseurs et l’inexistence de référence public sur le cycle de vie de produits. Ce qui nécessite l’alimentation d’autres projets pour mesurer le patrimoine dans la dette IT (migration dans le cloud).
Le processus de la gestion de la dette IT
Ainsi, la gestion de la dette IT devient une nécessité voire une impérative pour les DSI. Pour cela, elles doivent mettre en évidence autant que possible :
• le rôle du pilotage de la dette IT en réponse aux nouvelles exigences stratégiques, aux nouvelles fonctionnalités, et aux nouveaux besoins du métier ;
• le risque business, souvent associé à l’absence du remboursement de la dette IT ;
• la gestion efficace de la dette IT en maîtrisant les enjeux de sécurité obtenue .
En fait, ce processus s’avère être bien coûteux et complexe, mais incontournable. Pour une gestion efficace de cette dette IT, il faut y dédier un budget pour avoir un minimum de ressources financières. C’est une exigence qu’il faut privilégier même s’il y a d’autres difficultés liées aux délais pouvant freiner cette gestion ou aux priorisations des projets. Ainsi, l’un des enjeux majeurs de ce processus est d’assurer l’amélioration du pilotage de la dette IT et de veiller à son ancrage de façon durable. Pour cela, elle doit être placée au cœur des processus de l’entreprise tout en impliquant les acteurs majeurs et les parties prenantes au projet IT (CIGREF, 2021).
L’obsolescence IT
Un produit est obsolète lorsqu’il est dépassé en perdant une partie de sa valeur d’usage, c’est-à-dire la valeur perçue par l’utilisateur. Il peut avoir deux notions d’obsolescence : l’obsolescence indirecte (impossibilité de réparer ou de faire une mise à jour) et l’obsolescence psychologique liée aux effets de mode ou aux à la mise en avant de nouveaux produits plus efficace (d’après la publicité) sur le marché.
Ainsi, il importe d’évaluer l’obsolescence IT dans une entreprise pour des raisons budgétaires en ayant une vision sur quelques années en lien avec les systèmes, les matériels et les migrations à prévoir. En outre, il faut répondre aux besoins des utilisateurs en fournissant des services de qualité en termes de performance et d’usage.
Face aux enjeux grandissants des organisations, les DSI doivent assurer la sécurité de l’organisation au sein de l’entreprise en maîtrisant totalement les machines en évitant toute faille due à un manque de mise à jour. Dans ce cas, elles doivent garantir la capacité de l’entreprise à faire face aux changements en ayant les moyens de prévenir les changements organisationnels (DEMENE C & MARCHAND A., 2015).
L’obsolescence IT et ses victimes
Avant de déterminer les critères à prendre en compte dans l’obsolescence, il est important de bien discerner l’obsolescence programmée (peu éthique et illégale en France ) de l’inévitable obsolescence liée au cycle de vie des produits en phase de déclin .
Le Petit Larousse illustré définit l’obsolescence comme « un déclassement technologique du matériel industriel entraîné par l’apparition d’un matériel plus moderne, mieux adapté. »
Pour l’obsolescence programmée est « un ensemble de techniques destinées à réduire, lors de la conception d’un produit, sa durée de vie ou d’utilisation, afin d’amener le consommateur à le remplacer plus fréquemment » .
Que ce soit pour l’une ou pour l’autre, il existe deux segments principaux de personnes préjudiciées dont :
les victimes « grand public » qui sont constituées par les ménages servant des IT. Elles sont principalement impactées par l’obsolescence programmée qui s’avère être modéré, car l’impact se limite généralement à un surcoût de rachat ;
les victimes « Corporate » ou les sociétés qui subissent des conséquences allant d’une augmentation du risque à de lourdes pénalités financières pouvant mettre à mal la pérennité de l’association (BREBOIS J, 2021).
Dans tous les cas, l’obsolescence demeure une problématique en termes de développement durable dont sa principale conséquence est la croissance fulgurante des déchets (SCHOR, 2011). Ces déchets vont être incinérés ou enfouis ou encore envoyés dans les pays émergents dans lesquels, en raison de la pauvreté, tout est récupérable, réutilisable et échangeable (DEMENE C & MARCHAND A., 2015). L’obsolescence est le statut donné à une pièce ou un système informatique qui n’est plus disponible sur le marché ou qui n’est plus fabriqué par le fournisseur entraînant des coûts énormes et des retards faisant référence au type DMSMS (F. J. R. ROJO, ROY, S., & CHERUVU, 2012 ; F. R. ROJO, ROY, SHEHAB, 2010). Et aujourd’hui, nombreux sont les composants électroniques qui deviennent obsolètes. Cela est dû principalement à l’avancement technologique (O’DOWD, 2010). Et si l’on résume ce problème d’obsolescence, nous obtenons la figure suivante (Fig.5) :

Fig.5 : Apparition de l’obsolescence adaptée de BARTELS et coll., 2012
Les critères à prendre en compte dans l’obsolescence IT
Pour parler d’obsolescence, voici les différents critères qui doivent être considérés en analysant chaque couche : matériels – systèmes – applications – architecture avec le réseau :

l’usure qui peut arriver plus vite en fonction de la fréquence de son usage : ancienneté de la machine ou des disques durs (trop de bruit), …
les fonctionnalités offertes avec des besoins non-couverts par la nouvelle machine ;
le coût de fonctionnement : prix élevé des machines à utiliser ou à migrer ;
l’incompatibilité : les nouveaux entrants sont incompatibles avec les existants ;
la capacité : une entreprise qui se développe augmente en taille et donc, il a montée en charge, en consommation d’électricité, …
la sécurité : que ce soit humaine ou matérielle, c’est un critère non négligeable.
La typologie de l’obsolescence adaptée aux produits électroniques relatif au projet IT
Au cours de la réalisation d’un projet IT, on constate la mise sur le marché de façon régulière de produits nouveaux. Il s’agit du fruit des efforts d’innovation des entreprises qui ont tendance à rendre obsolètes les modèles précédents sur différents plans : technique, économique ou psychologique (KREZIAK et coll., 2016). Cela conduit à la mobilisation de deux champs complémentaires menant à l’exploration du remplacement du produit :
• la décision de remplacement et la notion de l’obsolescence qui y est liée. Cette obsolescence s’articule autour de l’obsolescence absolue et l’obsolescence relative (Tableau 1)
• la destinée des produits c’est-à-dire les décisions sur leur devenir lorsque l’usage n’est plus requis.
Tableau 1 : Typologie d’obsolescence relative et absolue (DEMENE C & MARCHAND A., 2015).

Cette typologie montre les situations d’élimination des équipements électroniques dans lesquelles les autorités politiques ne semblent pas vraiment concernés par l’obsolescence. C’est surtout les usagers qui sont davantage les responsables de la fin de vie prématurée du système ou d’un produit, et le fabricant de sa fin de vie technique . Effectivement, l’usager a une forte influence sur l’obsolescence psychologique, car il définit les caractéristiques esthétiques du système en plus des changements de situation personnelle et professionnelle (DEMENE C & MARCHAND A., 2015). Pour l’obsolescence technologique, économique et écologique, les responsabilités incluent tous les acteurs :
• l’obsolescence technologique : l’usager peut s’offrir un produit dernier cri, mais lorsqu’il trouve qu’il n’est pas compatible avec les technologies existantes, il est contraint de le changer ;
• l’obsolescence économique existe lorsque l’usager n’est pas conscient des éventuelles réparations de l’appareil, et même s’il le sait, le temps et le coût nécessaire pour la réparation peuvent être plus cher que l’achat d’un nouveau ;
• l’obsolescence écologique : la mise en œuvre de stratégies des autorités politiques vise à retirer du marché les produits énergivores (DEMENE C & MARCHAND A., 2015).
Tout cela montre 3 principales tendances des acteurs impliqués dans l’obsolescence d’un projet IT :
• le rôle prédominant du fabricant dans le cas d’une obsolescence programmée ;
• l’influence controversée de l’usager dans l’obsolescence relative ;
• la nébuleuse des autorités politiques (DEMENE C & MARCHAND A., 2015).
En fait, le fabricant a une influence sur la durée de vie technique des biens informatiques, car ce sont eux qui assurent le choix des matériaux, l’assemblage des composants et le conditionnement de la difficulté ou de la facilité de la maintenance ou réparation. La durée de vie d’un système informatique est donc planifiée par le fabricant (COOPER, 2004).
L’usager a une influence sur l’obsolescence absolue, donc la durée de vie technique des biens, car cela ne dépend uniquement du choix du fabricant, il dépend également du comportement de l’usager, de sa fréquence et intensité d’utilisation, mais également de l’entretien et de la maintenance du produit. D’ailleurs, la plupart des usagers ne font pas le nécessaire pour favoriser la pérennité des produits électroniques (EVANS & COOPER, 2010).
Même si l’influence des autorités publiques est de façon indirecte, elle n’est pas moins importante sur la durée de vie des systèmes électroniques. L’exemple concret est la transition du signal analogique vers le numérique éliminant massivement les téléviseurs cathodiques, notamment dans les pays développés (COOPER, 2010 ; CORSBIE, 2008).
Les départements impactés par l’obsolescence IT
Après avoir défini réellement l’obsolescence dans un projet IT avec les critères pouvant la déterminer, nous avons vu ses principales victimes. Néanmoins, il s’avère indispensable les départements impactés par cette obsolescence. Cela permet de mettre en œuvre les actions de stratégies et managements adéquates à chaque impact. Il s’agit des actions de gestions transversales à l’ensemble de l’organisation ayant pour but de minimiser les impacts (financiers, opérationnels, conformités, image de marque, …) liés aux indisponibilités définitives . Effectivement, les activités concernées par la gestion de l’obsolescence ont un impact entre multiples entités répartis dans différents départements ou services dont voici quelques-uns de manière non exhaustive (BREBOIS J, 2021) :

Département Conception (environnement de recherche et de développement ou R&D ) : là où la conception du produit est pensée, regroupant les premières étapes de création d’un produit ;
Département Développement : les concepts de faisabilités vont être intégrés vers un produit fini « industrialisable » en petite ou grande série ;
Département Production : produire, assembler les (sous-)composants pour avoir un produit fini. Il va assurer la mise en place de l’infrastructure nécessaire et suffisante permettant de produire les quantités nécessaires du produit ;
Département Service : assure le maintien ou entretien des matériels en service ;
Département Upgrade/Update : service veillant à la mise à jour des performances ou de la conformité aux nouvelles normes d’un produit existant ;
Département Recyclage : service garantissant la gestion de la fin de vie du produit vers un recyclage ou une mise à jour importante afin de pouvoir l’utiliser avec les attentes actuelles ;
Département des Ventes : sa fonction principale est de transformer un besoin client en une vente produit ;
Etc…
Tout cela nous montre que presque tous les départements au sein d’une organisation sont impactés par l’obsolescence. Il est donc important de prendre en compte le cycle de vie des composants, mettre en place une opération de sensibilisation, intégrer les aspects de gestion liés à tout niveau de l’organisation, et de disposer de données internes non restreintes. En fait, c’est une gestion complexe d’éléments constitutifs d’un assemblage élaboré permettant de trouver une solution aux composants obsolescents avant que la disponibilité de ceux-ci ne devienne problématique dans leur approvisionnement et crée de facto un scénario de crise à gérer en urgence (BREBOIS J, 2021).
c) Mise à jour ou mesure pour la pérennisation du projet
En connaissant tous ces critères d’obsolescence et ses impacts sur une organisation entière, il importe de faire une mise à jour ou prendre les mesures adéquates pour la pérennisation du projet. La connaissance des conséquences de l’obsolescence aide les dirigeants à mieux orienter ses décisions selon les besoins de l’entreprise. La suggestion de différentes stratégies peut être déployée pour améliorer les performances environnementales durant la réalisation du projet tout en réduisant son obsolescence.
Les conséquences de l’obsolescence du projet IT
A la suite de l’apparition de l’obsolescence, les conséquences sont multiples reflétant un risque associé à une probabilité d’occurrence. Ce qui forme le couple risque-probabilité augmentant les décisions rationnelles et allouant les ressources nécessaires. Ainsi, les impacts pouvant être trop critiques pour la viabilité de l’entreprise seront minimisés en sachant les conséquences suivantes :
a) la disponibilité du produit fini ou des services liés
Cela peut être due à :
• une indisponibilité totale : retrait forcé d’un produit du catalogue ;
• une extension des délais d’approvisionnement suite aux résolutions d’obsolescence survenues entre la chaîne d’approvisionnement et de fabrication (vente retardée) ;
• la non activation de certaines ventes : ventes ratées en raison d’un fournisseur alternatif de solutions.
b) le non-respect des engagements :
La difficulté à maintenir l’équipement retarde sur l’exécution des maintenances planifiées ou diminution de la qualité attendue ;
c)la diminution ou perte de revenu :
Cette diminution se traduit par :
• des pénalités contractuelles liées à un surcoût à charge du fournisseur n’assurant pas ses engagements ;
• un contrat à prix ferme n’étant plus rentable suite aux surcoûts de résolutions ou d’approvisionnements alternatifs39 ;
• un surcoût de résolution ;
d)la dégradation des performances qui se manifeste par la diminution des performances et le travail en mode dégradé parce que seule une partie des options originelles du produit est utilisée.
e) la diminution de l’image de qualité qui peut pénaliser les ventes futures. Par contre, une société qui maîtrise l’art de gérer l’obsolescence peut par son image renouveler plus facilement des nouveaux contrats, ainsi que la diminution du « goodwill »;
f) le cycle de vie des assemblages impactés se traduisant par des multiples révisions d’un même équipement (BOISSIE K, 2019).
Les systèmes produit-service (SPS)
Il s’agit d’une pratique pouvant jouant un rôle important dans la réduction de l’obsolescence des produits durables. Cela signifie la réduction délibérée de la durée de vie des produits et de leur dévaluation symbolique du point de vue des consommateurs et des entreprises dans les domaines du design des produits et du marketing (MUNTEN et coll., 2021). Pour profiter des effets des SPS orientés produit sur l’obsolescence, il convient d’étudier le type de services supplémentaires que les entreprises ou les parties prenantes du projet puissent associer à leurs produits. Ainsi, les managers, les régulateurs et les décideurs politiques peuvent adopter une stratégie qui les aide à lutter contre l’obsolescence.
Approches et outils proposés par les entreprises
Les modes de production et de consommation des pays développés ont suscité une prise de conscience générale des impacts environnementaux de l’obsolescence sur l’organisation. C’est un engagement portant particulièrement à la durée de vie des systèmes d’informations inclus dans les biens de consommation. D’ailleurs, c’est un concept qui s’est amélioré progressivement grâce aux principales préoccupations économiques et sociales de la pensée de cycle de vie (COOPER, 2013). En parallèle à ces études d’impact de l’obsolescence, d’autres organismes ont développé divers intérêts de recherche sur la durée de vie : stratégies et approches en design pour allonger la durée de vie des appareils, étude des relations usager/objet et des stratégies défiant l’obsolescence (PARK, 2010).
D’après ces approches, l’obsolescence peut être résolue en adoptant quelques solutions (BOISSIE K., 2019) :
d) L’achat d’un dernier lot
C’est une solution qui s’avère être la plus simple et elle consiste à rechercher les stocks disponibles en allant chercher à travers différents réseaux de distribution, même s’ils peuvent coûter cher, mais peuvent être utilisés même au-delà de la date indiquée par les constructeurs. Cela évite les risques de contrefaçons et de dégradation avec des coûts supplémentaires aux stockages et aux acquisitions.
e) L’utilisation d’une substitution et d’une alternative
Comme son nom l’indique, en cas d’obsolescence, il faut recourir à sa substitution en optant pour un produit 100 % identique à celui qui est obsolète. Cela implique notamment les caractéristiques et les designs.
A la différence de la substitution, une alternative est un composant du système ayant les mêmes fonctions, mais qui ont des caractéristiques différentes. L’alternative se présent comme un compromis.
f) La réclamation
Ce n’est pas une action en soi, mais il s’agit d’une conséquence faisant suite à une stratégie d’inaction. On réclame alors le paiement des conséquences de l’arrêt de livraison.
g) L’émulation
Cela concerne souvent le logiciel même s’il y a aussi certains hardwares. L’émulation a pour objectif d’utiliser un autre logiciel ou autre composant permettant de générer les fonctions assurées par les systèmes d’informations précédents.
h) La reconception mineure et majeure
On parle de reconception mineure quand on vise à reconcevoir juste une partie d’un produit ou d’un composant sans que cela affecte son design. La reconception est majeure quand on veut reconcevoir entièrement un produit ou une fonction.
i) Le choix d’après-vente
Le choix d’après-vente veille à la mise en place d’un réseau de récupération de pièces usagées afin d’opter pour un procédé de réparation. Cela permet de récupérer partiellement ou totalement un composant et de s’orienter vers sa rénovation pour le remettre sur le marché. Le choix d’après-vente est aussi appelé échange standard .
Chapitre III : ANALYSE ET RECOMMANDATIONS
Méthodologie et hypothèses
Afin de compléter notre revue de littérature et d’enrichir notre travail de recherche, nous avons choisi de réaliser une analyse qualitative en sélectionnant une dizaine d’experts en informatique et transformation digitale. Pour se faire, nous avons choisi de réaliser des entretiens individuels, semi-directif à réponses libres, enregistrés puis retranscrit (ANNEXE VI).
En amont, nous avions préparé une liste d’hypothèses à confirmer concernant les principales recommandations formalisées par et pour les DSI afin qu’elles puissent gérer au mieux le sujet de l’obsolescence d’un projet IT :
• l’adoption d’une approche présentant les risques business associés à l’obsolescence IT ;
• s’appuyer sur les enjeux de cybersécurité et de continuité de services ;
• la formalisation d’une cartographie du SI et mise en visibilité la dette et l’obsolescence IT ;
• la mise en place des indicateurs de suivi de l’évolution de l’obsolescence du projet IT ;
• la construction d’une grille de référence ou une matrice d’obsolescence des logiciels ;
• le développement d’un discours pédagogique ancré dans la réalité de son organisation ;
• la sensibilisation de la Direction générale et des directions métiers aux enjeux d’une maîtrise partagée du patrimoine IT ;
• la sanctuarisation d’un budget pour la gestion de la dette IT ;
• l’option de décommission des applications les moins utilisées ;
• l’intégration du décommissionnement des éléments du SI dans les projets de transformation ;
• l’utilisation de tous les projets de transformation numérique comme leviers de maîtrise de la dette IT ;
• s’appuyer sur la migration dans le cloud et sur les outils d’automatisation à disposition ;
• la mise en équilibre entre le maintien des compétences nécessaires sur le SI patrimonial (legacy) et l’évolution des compétences indispensables pour maîtriser les nouvelles technologies (CIGREF, 2021)
Suite à cela, nous avons retranscrit les réponses de notre échantillon en 6 sections permettant à la DSI de faire face au phénomène de l’obsolescence.
Aborder la gestion de l’obsolescence comme une pratique essentielle dans la gestion de projet informatique
La gestion de l’obsolescence doit être abordée comme une pratique essentielle dans la gestion d’un projet IT. Ainsi, il importe de gérer chaque outil qui compose le système d’information au lieu de le gérer dans sa globalité. Cela consiste à considérer le cycle de vie d’un logiciel, d’une application, ou autre partie du projet qui prend fin dès que son support s’arrête. Cependant, la perpétuelle quête de nouveautés devient dangereuse parce que les technologies modernes coûtent plus cher que le besoin de renouvellement des applications (BOHNKE, 2010). Même si certaines entreprises parviennent ainsi à utiliser certaines de leurs applications depuis plusieurs décennies avec l’inexistence de support, cela peut entraîner de nombreux risques qui doivent être évalués dès l’achat et l’implantation de l’outil (PILNARD M, 2015).
La gestion de l’obsolescence a pour objectif de minimiser de façon optimale les coûts supplémentaires et l’impact négatif de l’obsolescence. Elle est régie par la norme IEC 62402 fournissant des orientations et des lignes directrices aux entreprises afin de les aider mettre en place un processus efficace qui leur permet de gérer l’obsolescence avec un support tout au long du cycle de vie du projet IT (ADETUNJI, BISCHOFF, & WILLY, 2018 ; ZAABAR, BEAUREGARD, & PAQUET, 2018). Il existe trois niveaux de gestion de l’obsolescence : la gestion réactive, proactive et stratégique (BARTELS, ERMEL, SANDBORN, ET AL., 2012 ; P. SANDBORN, 2013).
La gestion réactive
Dans le cas pratique, les entreprises ne possèdent pas de méthodes proactives de gestion de l’obsolescence et elles sont obligées de compter sur des stratégies réactives à court terme. Parmi les approches réactives les plus connues, il y a :
• le stock existant : stock détenu par la chaîne d’approvisionnement contenant les composants de rechange originaux qui doit être suffisant pour assurer l’approvisionnement tout au long du cycle de vie restant du système (BARTELS, ERMEL, PECHT, & SANDBORN, 2012A ; Z. SHI & LIU, 2020) ;
• le dernier achat (last time buy) : acheter une quantité suffisante pour supporter la production jusqu’à la reconception (C. JENNINGS & TERPENNY, 2015) ;
• la substitution d’un composant (alternate part) : remplacer un équipement ou un composant par un autre ayant la même performance, la même dimension et la même caractéristique technique (GRICHI Y., 2020).
Si l’entreprise ne dispose pas les moyens pour se procurer les composants requis, ces approches ne peuvent être que temporaires et ne peuvent engendrer que des coûts importants non prévus.
La gestion proactive ou méthodologie à long terme
La gestion proactive est basée sur la surveillance proactive des informations relatives au cycle de vie d’un composant d’un projet IT. Elle permet d’éviter l’arrêt de production. Ce qui donne plus d’importance à la prévision de l’obsolescence (GRICHI Y., 2020).
La gestion stratégique
C’est la combinaison de la gestion réactive et proactive permettant de minimiser le coût du cycle de vie. La prévision de l’obsolescence s’utilise ainsi comme une entrée dans un niveau de gestion stratégique (GRICHI Y., 2020).
La stratégie de prévision de l’obsolescence
Quand on parle de prévision, il s’agit d’une estimation probabiliste pour un événement quelconque. Elle fournit aux décideurs des informations utiles à la gestion proactivement de l’écart entre ce que sera l’avenir et ce qu’on souhaite qu’il soit (PARVIN & BERUVIDES, 2017).
La prévision de l’obsolescence est alors une approche de gestion proactive permettant aux fabricants des systèmes d’information d’identifier en avance l’obsolescence des composants. Elle est basée sur des méthodes qualitatives et quantitatives faisant que les données soient disponibles pour être collectées ou qu’il n’y en a aucune. Dans ce cas, la meilleure approche de prévision est d’opter pour la méthode qualitative (GRICHI Y., 2020). Pour estimer le risque d’obsolescence, la méthode Delphi est la plus appropriée (ROJO et al, 2012) qui est une méthode basée sur des questionnaires et des enquêtes réalisées auprès des experts du domaine. Quant aux méthodes quantitatives d’estimation du risque d’obsolescence, il y a la prévision du risque et la prévision du cycle de vie avec deux démarches possibles :
• la prévision à long terme qui peut aller jusqu’à plus d’un an : pour une gestion proactive basée sur la planification du cycle de vie afin de soutenir un système ;
• la prévision à court terme : observée à partir de la chaîne d’approvisionnement (réduction du nombre de sources et des stocks, augmentation du prix (GRICHI Y., 2020).
La figure (Fig.6) suivante représente une technique de gestion de l’obsolescence d’un projet IT dans le secteur aéronautique. Il l’appelle par « Obsogérance » Serma technologies. C’est une figure qui peut être reprise et adoptée dans différentes entreprises menant un projet IT.

Fig.6 : « OBSOGERANCE » Serma technologies (BOISSIE K., 2019)
Prendre en compte tout au long du projet l’aspect budgétaire pour une maîtrise des choix clés
Dans la gestion de l’obsolescence d’un projet IT, attribuer un budget informatique est incontournable pour une maîtrise des choix clés de solutions supports adoptées. Tout au long du projet, l’entreprise doit se lancer minutieusement dans la réalisation de son aspect budgétaire DSI. C’est un exercice très stratégique qui requiert une plus grande attention afin d’éviter les mauvaises surprises tout en boostant sa productivité. En général, dans la gestion de l’obsolescence, la connaissance des critères de changement d’une machine est indispensable pour pouvoir l’éviter. En effet, une machine, notamment un ordinateur, doit être changé
• lorsqu’elle est amortie ;
• lorsqu’elle n’est pas upgradable ou ne comporte pas de vulnérabilité ;
• lorsque sa mise à jour coûte trop cher (coûts des projets applicatifs, de maintenance, de cybersécurité, …) ;
• lorsqu’elle est incompatible avec les nouveaux matériels ou nouveaux logiciels.
Ainsi, si un de ces problèmes se présente, la DSI doit informer la Direction Générale pour qu’elle puisse prévoir un budget pour le remplacement de la machine. Cela permet à la DSI de définir avec la Direction Générale les critères propres de l’obsolescence IT de l’entreprise. Il faut déterminer le seuil de sécurité, de performance, budgétaire et de fonctionnalité. Il y a également les critères liés à l’environnement et à la responsabilité environnementale.
En prenant en compte l’aspect budgétaire du projet IT, l’entreprise peut prévenir et lutter contre l’obsolescence IT précoce. En amont, elle doit choisir des produits (machines, logiciels, …) plus solides et réparables permettant d’optimiser leur rentabilité. L’idéal est d’acheter une machine puissante ayant une grande usabilité. En cours de vie, l’un des meilleurs moyens de prévenir l’obsolescence est d’interchanger les utilisateurs. Il se peut qu’une machine obsolète pour un développeur ne l’est pas forcément pour un autre technicien. Enfin, pour une machine en fin de vie, il faut upgrader la machine. Dans tous les cas, la maîtrise des choix clés adaptés à l’entreprise dépend de son aspect budgétaire. La gestion de l’obsolescence IT doit être évaluée en veillant si les OS sont toujours supportés par l’éditeur. Il convient de voir la date de maintenance et la date d’extension de support ainsi que la structure et la répartition de son budget (CIGREF, 2021).
Rationnaliser et durabiliser les infrastructures informatiques et les logiciels
Le meilleur moyen de lutter contre l’obsolescence d’un projet IT est de rationnaliser et durabiliser les infrastructures informatiques et les logiciels. Cela consiste à sensibiliser la Direction Générale de l’entreprise et les directions métiers sur la connaissance et la compréhension de la notion d’obsolescence IT. C’est un travail qui doit être confié à la DSI en assurant l’identification de l’ensemble de moyens et outils pédagogiques essentiels permettant de les sensibiliser. C’est une sensibilisation aux enjeux du pilotage de l’obsolescence IT nécessitant un travail collaboratif pour y répondre (CIGREF, 2021).
Effectivement, pour avoir des infrastructures informatiques et logiciels durables, cette sensibilisation est d’une grande importance pour évoquer plusieurs risques, menaces ou contraintes de leurs obsolescences (Fig.7). Chacun de ces risques, menaces ou contrainte suivants peuvent constituer, en retour, une source d’opportunités :
• les risques de cybersécurité : pertes de service, vulnérabilité de l’OS ;
• les risques de panne ou de discontinuité de service : impact sur les services critiques, sur les utilisateurs ou sur les directions métiers ;
• le crédit dû à des coûts excessifs aux extensions de support, mais qui ne répondent pas à la lutte contre l’obsolescence ;
• les contraintes légales qui sont particulièrement exigeantes dans certains secteurs ;
• les dettes (technique et applicative) qui empêche les transformations en profondeur de processus et les investissements numériques.

Fig.7 : Principaux arguments pour la sensibilisation de la Direction Générale et les directions métiers aux enjeux de l’obsolescence du projet IT (CIGREF, 2021)
Dans un projet IT, après l’identification d’une obsolescence, il y a la rationalisation liée à la globalisation avec réticence des collaborateurs au changement. L’entreprise fait face à un problème d’administration les utilisateurs refusent souvent les décisions managériales, car il n’y a pas de réelle stratégie (PILNARD M, 2015).
Maîtriser l’évolution de l’architecture informatique
La veille technologique
La veille technologique est une activité incontournable dans le processus de la mise en place et de la définition de la stratégie et de l’innovation. Elle est orientée vers l’obtention d’informations pour dynamiser l’innovation avec des connaissances externes à l’entreprise . La veille technologique est essentielle en s’intéressant à toutes les offres qui se présentent sur le marché. Il importe de considérer le cycle de vie et les dates propres de chaque outil. Pour lutter contre l’obsolescence d’un projet IT, il est important de bien maîtriser l’évolution de l’architecture informatique. Effectivement, l’innovation dans le secteur informatique se trouve dans la volonté de modernisation qui est soutenue par l’accélération du cycle de vie des produits immatériels (PILNARD M, 2015). En mettant en œuvre cette innovation face à l’évolution incessante du système informatique, on peut externaliser la veille technologique chronophage dans le cadre de management de l’obsolescence. Cela influence le choix des composants donnant accès à des services de profils de cycle de vie (BOISSIE K, 2019). Grâce à la maîtrise de l’évolution de l’architecture informatique, on peut placer chaque composant sur une courbe de cycle de vie pour déterminer si un produit risque de sortir prochainement du catalogue ou au contraire, il fait partie des produits émergeants (Fig.8).

Fig.8 : Exemple de représentation des solutions supports dans le management de l’obsolescence (BOISSIE K, 2019)
Pour mieux maîtriser l’évolution de l’architecture informatique dans la gestion de l’obsolescence IT, certains cabinets de conseil comme Gartner (2008) ont déjà trouvé la nécessité de placer la veille technologique et la modernisation au centre des stratégies d’entreprise (KYTE, 2008). Si le but essentiel est de moderniser le système informatique, il s’avère indispensable d’appliquer une politique de gouvernance à son système de d’information (BOHNKE, 2010). La mise en œuvre de cette modernisation et gouvernance du SI se fait par la combinaison de cinq piliers regroupant les moyens de gestion et régulation à instaurer au sein de l’entreprise (Fig.9).

Fig.9 : Les cinq piliers de la gouvernance des systèmes d’information, d’après BOHNKE (PILNARD M, 2015)
L’urbanisation
Outre la mise en place de la gouvernance des systèmes d’information (Annexe V), l’urbanisation est aussi une option pour l’entreprise permettant d’atteindre ses objectifs. En plus de ses enjeux techniques et applicatifs dans la modernisation, il représente un enjeu organisationnel potentiel (BOHNKE, 2010). L’urbanisation indique “la démarche qui consiste à rendre un système d’information plus apte à servir la stratégie de l’entreprise et à anticiper les changements dans l’environnement de l’entreprise” (CIGREF, 2003). Elle facilite la gestion de toutes les technologies et les différents processus au sein de l’entreprise tout en apportant une nouvelle optique d’agilité (PILNARD M, 2015). L’urbanisation est une nouvelle manière de gouverner un système d’information pour mieux le piloter parce qu’elle représente une opportunité de reprendre son contrôle. Elle permet à la fois de regarder vers l’avenir tout en prenant en considération les éléments déjà implantés dans le passé. Ces derniers sont tout autant des atouts que des risques à cause de leur impact crucial sur l’organisation (BOHNKE, 2010).
L’urbanisation est très utile lorsque l’entreprise souhaite instaurer de nouvelles technologies dans son système d’information. Elle permet de :
• faciliter la vision globale sur le système d’information et son utilisation ;
• mieux contrôler le cycle de vie des applications (HUET, 2012).
Dans une réelle dimension stratégique de l’entreprise, l’urbanisation du système d’information s’explique sur quatre différentes strates (Fig.10) qui peuvent être classées suivant trois visions différentes :
• Vision métier : architecture métier (pourquoi ?)
• Vision fonctionnelle : architecture fonctionnelle (comment ?)
• Vision informatique : architecture applicative (comment ?) et architecture technique (avec quoi ?).

Fig. 10 : Strates d’une urbanisation selon CIGREF en 2003 (PILNARD M, 2015)
Enfin, dans la modernisation du système d’information, la gestion de l’obsolescence du projet IT est facilitée même elle est un fait inévitable et naturel. Mais grâce à l’urbanisation, le changement et la variabilité de l’environnement deviennent gérables. Dans la phase de modernisation, il suffit de mettre en évidence la transversalité du projet IT concernant la DSI et les autres métiers de l’entreprise (PERCIE du SERT, 2012).
Rester à l’écoute et prévoir les risques pour renforcer la sécurisation
Face à l’obsolescence du projet IT d’une entreprise, la DSI doit rester à l’écoute de tous les collaborateurs au sein de l’entreprise. Chaque utilisateur d’un système d’information a ses besoins spécifiques tant pour l’aspect matériel que pour l’aspect applicatif, mais cela dépend de l’entreprise. Cela implique une forte communication pour prévoir différents risques pour un bon achèvement d’un projet. Afin de renforcer la sécurisation du système d’information de l’entreprise, la DSI provoquer l’échange en invitant tous les acteurs et toutes le parties prenantes (directes et indirectes) au sein de l’entreprise à fournir le maximum d’informations. Si chaque utilisateur d’une machine ou d’un logiciel, le risque d’obsolescence d’un projet IT diminue largement.
Sachant que la communication n’est nullement basée sur la technologie, un bon manager de la DSI doit donner envie de communiquer. Il peut dynamiser des échanges grâce à son sens de responsabilité de manager . En donnant à chaque collaborateur la possibilité d’exprimer son attente vis-à-vis du système d’information utilisé dans l’entreprise, la DSI peut recueillir une grande quantité d’informations qui lui permet de prévoir les risques d’avoir des machines obsolètes. Dans un projet IT, la cause majeure d’un échec est la pénibilité élevée pour maintenir le référentiel à jour par rapport aux bénéfices d’usage attendu.
En optant pour l’expression fonctionnelle du besoin, la DSI peut répondre facilement aux attentes des utilisateurs. Seulement, ces derniers doivent donner une information pertinente, bien ciblée et avec un vocabulaire soutenu. Cela doit être également fiable, utilisable, consultable et facilement interrogeable. En même temps, la DSI doit faciliter l’accès immédiat aux informations recueillies (SICOT J, 2006) .
Contrôler les coûts de fonctionnement
Tous comme les autres types de projet, le projet IT a un coût et son estimation est une phase délicate tout le long du processus. L’élaboration et le processus de management des coûts de fonctionnement d’un projet IT (Fig.11) a lieu bien avant son lancement. Suite à cela, il est possible d’entamer la définition du budget du prévisionnel du projet. Pour mieux contrôler les coûts de fonctionnement d’un projet IT afin de limiter les risques de son obsolescence, il faut définir dès le début les éléments de base qui doivent le constituer :
• Planning initial du projet ;
• Durée de chaque tâche et durée totale du projet ;
• Quantité des ressources nécessaires : matérielles, humaines, …

Fig.11 : Processus de management des coûts de fonctionnement d’un projet
Une fois tous ces éléments définis, il est important de déterminer les sources de coûts :
• La décomposition classique : coûts de structure et de fonctionnement
• Les coûts internes et externes : contrats d’infogérance et des licences logiciels,
• Les axes de mesure : études, exploitation et assistance, management, …
• L’inventaire des ressources et activités ;
• Les coûts complexes à mesurer : coûts services, utilisateurs, ….
Conclusion
Toute organisation aujourd’hui ne peut s’opposer à l’utilisation d’un système d’information. Il joue le rôle de support et d’aide aux humains. Afin d’éviter tout risque d’obsolescence, le système d’information inclut dans un projet IT doit faire l’objet d’un suivi strict de la part des acteurs clés au sein de l’entreprise. D’ailleurs, un système d’information doit être robuste et résilient pur qu’il puisse être l’un des piliers de la stratégie d’entreprise. Il est capable d’évoluer au bon rythme pour répondre aux enjeux des directions d’entreprise. Il doit ainsi être en position de pouvoir répondre aux attentes des entreprises qui sont d’autant plus fortes afin d’assurer la continuité des services pour les utilisateurs et les clients ainsi que la continuité des activités de la DSI (direction du système d’information). Si un des composants de ce système devient obsolète, cela impacte fortement l’évolution du système et la stratégie de l’entreprise.
L’obsolescence a été abordée dans cette étude comme étant la perte ou la diminution d’une valeur d’un composant d’un système d’information. Cela nous a mené à décrire les différentes typologies d’obsolescence pour pouvoir répondre à notre problématique qui est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT ?
Tout au long de notre étude, nous avons répondu à cette question en détaillant les concepts et les études sur l’implication de l’obsolescence dans la gestion d’un projet informatique et technologique (projet IT). Nous avons intégré l’aspect des responsabilités entre usagers, fabricants et autorités politiques. Nous avons quand même pu développer les normes et standards appliquées à la gestion de l’obsolescence qui se présente de différentes façons dans un projet IT. Malgré tout, l’obsolescence reste relativement peu étudiée (par rapport à l’obsolescence programmée). En outre, la stratégie de conception et d’approvisionnement impacte fortement sur le risque d’obsolescence qu’il convient de la considérer comme une bonne prédiction.
Les recherches et analyses empiriques que nous avons effectuées après une revue des cycles de vie nous ont permis de revoir les recommandations nécessaires pour avoir une vision pratique. Cela nous a également permis de dégager des solutions réalistes et fiables. La première solution est de maîtriser le système d’information de l’entreprise en cartographiant son patrimoine et en montrant précisément la dette et l’obsolescence IT qui y sont associées. Ensuite, il faut évaluer les risques et les présenter tout en les partageant avec la Direction générale et les directions de métiers. Enfin, il y a la veille technologique qui permet d’adopter la gouvernance et l’urbanisation du système d’information.
Tout cela nous permet de dire que l’entreprise doit prévenir l’obsolescence du projet IT. La gestion de l’obsolescence peut être très coûteuse si tous les collaborateurs refusent tout changement. Or, de nos jours, la réparation n’est plus efficace, elle coûte cher que l’achat d’un nouveau système. Ainsi, le challenge est de pouvoir convaincre tous les acteurs clés d’un projet IT d’accepter le changement. Tous les utilisateurs doivent être convaincus qu’il faut suivre l’évolution de l’architecture de l’information pour parvenir à résorber l’obsolescence et la DSI doit réussir à ancrer durablement la gestion de l’obsolescence dans ses bonnes pratiques.

BIBLIOGRAPHIE
I- OUVRAGES

Jean-Yves Moine, Xavier Leynaud – Le grand livre de la gestion de projet édition AFNOR 2013. Page 32, 33, 34 et 35, 102
Mounib MEKHILEF et Bernard YANNOU. Conception intégrée assistée par ordinateur.
Bachir Mazouz et Patrick Cohendet
Michel Kalika, Frantz Rowe et Bernard Fallery, Systèmes d’information et management des organisations. Cas et applications. Vuibert, 2012. pages 254-256
Bohnké Sabine. modernisé son système d’information (2010). Eyrolles. Edition
BOISSIE K. Méthodes et outils pour la maîtrise de risques en ingénierie de l’obsolescence dans un contexte incertain : application à un équipementier automobile. Risques. (2019). Université Paris-Saclay. Français. ffNNT : 2019SACLC105ff. fftel-02651438
BREBOIS, J. Stratégie et management de l’obsolescence dans le cadre d’équipements à long cycle de vie. (2021). Louvain School of Management, Université catholique de Louvain.
DAVIS, F. A technology acceptance model for empirically testing new end-user information systems: theory and results. (1986). Doctoral dissertation, MIT Sloan School of Management, Cambridge, MA (USA).
DAVIS, F. D. Perceived usefulness, perceived ease of use, and user acceptance of information technology. (1989). MIS Quarterly, 13(3), 319-340.
DAVIS, F. D., BAGOZZI, R. P., & WARSHAW, P. R. User acceptance of computer technology: A comparison of two theoretical models. (1989). Management Science, 35, 982–1003.
Taché, Philippe. Conduire un projet informatique. Pages 29 et 30. Edition eyrolles, 2014.
HSIAO, C. H., & YANG, C. The intellectual development of the technology acceptance model : a co-citation analysis. (2011). International Journal of Information Management, 31, 128-136
-Wilfrid AZAN et Tarek MILOUD. Évaluation des projets de système d’information : une approche par les options réelles (2013). Recherches en Sciences de Gestion 2013/3 (N° 96), pages 69 à 89
KALIKA, M. La théorie du millefeuille et l’usage des TIC dans l’entreprise. Revue française de gestion. Lavoisier. (2007). n°172, 192 p.
J. KALLINIKOS. « Deconstructing information packages: Organizational and behavioural implications of ERP systems ». (2004). Information Technology People, 17, pages 8-30
D. GEFEN. « What makes an ERP implementation relationship worthwhile: Linking trust mechanisms and ERP usefulness ». 2004. Journal of Management Information Systems 21 (1). Pages 263-288
MUNTEN P., VANHAMME J., SWAEN V. Réduire les pratiques d’obsolescence du point de vue des systèmes produit–service orientés produit : un agenda de recherche. (2021). https://doi.org/10.1177/0767370120984755
P. BESSON. « Les ERP à l’épreuve de l’organisation », 1999) Système d’Information et Management, 4, 21-51.
FX. DEVAUJANY. « Evaluer la valeur à l’usage de l’informatique : Une architecture de tableau de bord ». (2007). Revue Française de Gestion, 173, 2007a, 31-47.
FX. DEVAUJANY. « Modeling sociotechnical change in is with a quantitative longitudinal approach: The ppr method ». (2007b). International Journal of Technology and Human Interaction 3, 2007b, 71-95.
Serge Latouche. Bon pour la casse (2012). Edition les liens qui libère.
II- RAPPORTS ET REVUES
Brent Furneaux et Michael Wade An exploration of organizational level information systems discontinuance intentions. Revue Management Information Systems Research Center, University of Minnesota. MIS Quarterly, Vol. 35, No. 3 (September 2011), pp. 573-598
Cigref. Pilotage de la dette de l’obsolescence IT (2021)
DEMENE C, MARCHAND A. L’obsolescence des produits électroniques : des responsabilités partagées. (2015). Les ateliers de l’éthique. Volume 10, numéro 1, p. 1-182.
JENNINGS, C., & TERPENNY, J. P. (2015). Taxonomy of Factors for Lifetime Buy. IIE Annual Conference. Proceedings, 430-436. Retrieved from http://search.proquest.com/docview/1791989172?accountid=27231
Lori Podolsky Nordland. The Long and Short of IT: The International Development Research Centre (IDRC) as a Case Study for a Long-term Digital Preservation Strategy (2007)
Mario CASTELLAZZI, Alexandre MOATTI, Bernard FLURY-HERARD et Bernard SCHWOB, rapport du CGEDD sur l’obsolescence logicielle (2021)
O’Dowd, R. J. (2010). A Survey of Electronics Obsolescence and Reliability.
SHI, Z., & LIU, S. (2020). Optimal inventory control and design refresh selection in managing part obsolescence. European Journal of Operational Research, 287(1), 133-144. doi:10.1016/j.ejor.2020.04.038
III- MEMOIRES ET THESES
Marine Pilnard. Mémoire sur « Obsolescence des systèmes d’information : quels sont les facteurs à prendre en compte après l’identification de l’obsolescence dans le domaine des systèmes d’information ? » Grenoble I.A.E 2014-2015
Mohamed Amellal. Thèse sur la « modélisation de l’immunité électronique des composants en vue de la gestion de l’obsolescence des systèmes et modules électroniques ». Insa Rennes soutenue le 14/12/2015
Jean-Pierre Boutinet. 7. Le projet technologique pris au jeu paradoxale de la motivation et de l’efficacité. Anthropologie du projet. P.237- 271
Grichi Yoshra. Développement et optimisation des stratégies de réponse à l’obsolescence via des modèles prédictifs. Université de Québec. Octobre 2020.
Rojo, F. R., Roy, R., & Kelly, S. (2012). Obsolescence risk assessment process best practice. Paper presented at the Journal of Physic s: Conference Series.
Rojo, F. R., Roy, R., & Shehab, E. (2010). Obsolescence management for long-life contracts: state of the art and future trends. International Journal of Advanced Manufacturing Technology, 49(9-12), 1235-1250. doi:10.1007/s00170-009-2471-3

IV- WEBOGRAPHIE
Numérique : les propositions pour lutter contre l’obsolescence logicielle, publier le 10/06/2021 (Disponible sur : https://www.economie.gouv.fr/numerique-propositions-lutter-contre-obsolescence-logicielle (consulté le 21/02/2022))
Ahouandjinou, F. La gestion de l’obsolescence [en ligne]. 2015. Disponible sur : http://www.airmis.com/la-gestion-de-l-obsolescence (consulté de 04/05/2022)
Lapoix, S. Obsolescence programmée : comment les entreprises entretiennent le cycle du jetable [en ligne]. 2011. Disponible sur : http://owni.fr/2011/05/01/obsolescence-programmee-comment-les-entreprises-entretiennent-le-cycle-du-jetable/ (consulté de 05/05/2022)
Sandborn, P. Beyond Reactive Thinking – We Should be Developing Pro-Active Approaches to Obsolescence Management Too! [en ligne]. DMSMS Center of Excellence Newsletter. 2004, vol. 2, n°4. Disponible sur : http://www.enme.umd.edu/ESCML/Papers/ProactiveObsolescenceManage ment.pdf (consulté le 04/05/2022)
VI- VIDEOGRAPHIE

Retransmission du Colloque « Numérique et Environnement », le 8 octobre 2021, à Bercy (disponible sur : https://www.economie.gouv.fr/colloque-numerique-environnement-8-octobre( consulté le 21/02/2022))
Colloque sur la sobriété numérique, le 17 décembre 2021 (disponible sur : https://www.cigref.fr/la-mesure-et-l-obsolescences-au-coeur-du-dernier-colloque-sobriete-numerique-du-cigref (consulté le
Cas du système de paiement des soldes des militaires français (Louvois) défaillant.
https://www.youtube.com/watch?v=NeHlhjKv7AE
Problème du projet informatique lors du projet SIRHEN de l’éducation national français
https://www.youtube.com/watch?v=eNSIwrAuTvQ
ANNEXE :
Annexe I : Typologie de risque dans un projet IT (ROSS et al., 2002)

Annexe II : Schéma de l’incertitude technologique et de l’incertitude stratégique dans les ERP (AZAN W & MILOUD T., 2019)

Annexe III : Problématique générale du changement (THEVENOT, 2015)

Annexe IV : Huit facteurs clés à prendre en considération lors de la prise de décision de l’obsolescence dans un projet IT (PILNARD M, 2015)

Annexe V : Méthodes utilisées pour la mise en place de la gouvernance du système d’information
ANNEXE VI : retranscription des entretiens individuels
Interviewé 1 :

D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Le système d’information : toutes les ressources qui concernent la gestion de l’entreprise. Il doit être performant d’un point de vue technique. La lenteur n’est pas acceptable, surtout pour l’utilisateur final qui utilise les technologies dans sa vie personnelle aussi. En plus, la maintenance manuelle n’est plus possible, car c’est une tâche chronophage, sans aucune valeur ajoutée. Le SI performant ne requiert que peu d’administration, mais plus de rapidité doit faire ce qu’on lui demande.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Il n’évolue pas si vite que ça et a tendance à être stable. D’ailleurs, les montées de versions sont fréquentes tout en étant globales et flexibles. On constate qu’il y a peu de différences de fonctionnalités entre différentes versions.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
Ben, obsolescence, quand il s’agit d’un outil que l’on n’a pas fini d’amortir, c’est-à-dire qu’il faut changer d’outil avant même la fin de son amortissement. Il provoque des dysfonctionnements et devient moins performant, donc il a besoin d’un changement. C’est l’ensemble des phénomènes rendant un produit non utilisable quand il ne remplit plus sa fonction initiale ou alors, son utilisation devient pénible.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
Dans la sphère privée surtout avec les smartphones et les changements de systèmes d’exploitation, et plus encore dans la sphère professionnelle avec tous les types de logiciels qu’il faut maîtriser.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Oui, pour l’aspect matériel, mais moins pour l’aspect applicatif montrant le suivi de changement de version, de fin de support.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Lorsque le service offert par le SI ou le projet IT ne correspond plus aux besoins ou lorsque les composants sont usés. Mais pour un logiciel, il faut bien voir que leurs composants sont usés ? Encore une fois, le système doit correspondre à la façon de travailler dont les gens travaillent, ils sont contents et le changement est moins adapté.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Ce sont les éditeurs, les commerciaux, le propriétaire et les fabricants de hardware.
Que faut-il faire pour mieux gérer cette obsolescence ?
Primo, évaluer les risques. Secondo, il faut suivre les décisions de l’éditeur et planifier le decommissioning. L’important : pas de précipitation avec de mauvais tests pouvant causer beaucoup de risques. Tertio, faire de la veille technologique et être à l’écoute du marché, être proactif et avoir des ressources.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Fiabilité. Je trouve que l’implication du top management est peu importante. Mais, là il y a une anecdote : lorsque le business décide de prolonger la durée de vie, l’investissement est trop lourd (temps et argent). D’ailleurs, si les dirigeants ne veulent pas investir, ils ne le feront jamais, mais s’ils le font, cela leur coûtera vraiment cher et ils se mettront dans une très mauvaise situation. Ce qu’il faut considérer c’est que l’extension de support peut parfois coûter cher et les bugs ne sont pas un facteur s’il y a un support. Enfin, une petite entreprise se soucie moins de l’obsolescence et il n’y a pas de réelle stratégie et elle se laisse subir alors par l’obsolescence.
Interviewé 2
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Un SI, c’est l’ensemble de toutes les ressources permettant de collecter, stocker et distribuer différentes informations dans l’entreprise. Il est performant quand le temps de réponse est correct avec des fonctionnalités standards : tri, export, recherche intelligente, ergonomie. Il doit faire preuve de souplesse avec le moins de latences possible. Il faudrait qu’il utilise un identifiant unique et sans multiples accès.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Il s’accélère et on peut citer l’AS/400, par exemple, qui a été utilisé plus de 30 ans dans des entreprises. Aujourd’hui, les applications ont une durée de vie de plus en plus réduite que tous les 5 ans, il faut désormais se reposer des questions, reformer et documenter.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
Il y a obsolescence quand c’est la fin de support ou de génération d’un produit. Il peut s’agir aussi d’un changement de processus ou d’un critère de maintenance. On peut aussi parler d’un système trop vieux qu’on ne peut plus faire évoluer par manque de ressources, en lien avec la sécurité.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
En entreprise, il y a les changements de système d’exploitation. Dans la vie personnelle, il y a les appareils qui fonctionnent avec de la 2G, puis on s’est habitué à la 4G avec les smartphones, du coup l’utilisation des fonctionnalités devient pénible.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Cela dépend. L’obsolescence est plutôt subie, et l’entreprise ne s’en occupe que lorsqu’elle fait face aux contraintes de fin du support, par exemple. En général, je trouve que l’entreprise s’occupe plus du déploiement, mais pas de l’arrêt des outils.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Soit il n’y a plus de maintenance, soit le côté esthétique (trop ancienne) qui ne correspond plus aux besoins. Quand il ne favorise plus la simplification des processus.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Les éditeurs ont une grosse part, d’abord, et bien sûr, tout le monde est impliqué : le top management, l’end-user (à lui de dire si le système ne correspond plus à ses attentes). La migration n’est effectuée que si elle vient de la décision managériale.
Que faut-il faire pour mieux gérer cette obsolescence ?
Anticiper et faire une veille technologique, voir ce que se produit sur le marché et faire évoluer avec son éditeur le logiciel pour être en phase avec la réalité. Il faut aussi apprendre la gestion de versions, de petites évolutions ponctuelles sont moins chères qu’une grosse une fois par an.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Dans notre entreprise, je constate surtout les facteurs humains qui affichent la réticence au changement. Ils veulent un outil performant, mais ils ne l’utilisent pas. Après, il y a les bugs liés à la maintenance, la rationalisation liée à la globalisation. Ainsi, les décisions managériales sont souvent refusées par les utilisateurs qu’il devient impossible de suivre la ligne directrice.
Interviewé 3
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Un système d’information, c’est un élément central de l’entreprise pour véhiculer les informations. Un SI performant doit être plus fiable que moderne avec des interfaces qui fonctionnent bien. Il doit être également un système disponible, fiable et carré avec des règles d’audit, de suivis et de droits d’accès.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
De stable à tendance à s’accélérer notamment en ce qui concerne les systèmes d’exploitation Windows et les différentes applications.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
L’obsolescence est un phénomène sérieux de nos jours. Plus on avance dans le temps et plus cela devient commercial. Elle peut être bénéfique si elle permet d’avoir un système avec les dernières possibilités techniques. On peut parler aussi d’obsolescence esthétique avec l’ergonomie.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
Dans la sphère privée, l’iPhone est un très bon exemple, mais aussi les téléviseurs avec la TNT. Les appareils n’ont pas les mêmes fonctionnalités, mais on peut le faire évoluer selon ses besoins et cela complique les systèmes. Pour basculer sur un autre outil, on arrive sur des outils trop restreints. Il y a également la montée de version qui coûte cher.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Cela dépend de l’entreprise. Elle doit avoir un planning et être proactive dans le remplacement des outils pour être en avance ou au moins à l’heure. Pourtant, beaucoup d’entreprises font l’upgrade en sachant pertinemment qu’elles sont déjà en retard.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Un projet IT est obsolète quand cela met en péril le reste du système d’information. Par exemple, Windows XP n’a plus de support, mais il y a encore de vieux périphériques qui fonctionnent sur ce système d’exploitation. Pourtant, cela cause un problème de sécurité. C’est aussi le cas lorsque le hardware rend le software obsolète, et vice-versa.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Chez nous, ce sont les éditeurs avec l’implication des end usés qui prennent les opportunités à expliquer aux utilisateurs.
Que faut-il faire pour mieux gérer cette obsolescence ?
Mettre en place une cellule de veille active tout en restant proactif, communiquer et aussi créer un système où sont indiquées les dates limites d’utilisation.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Opter pour des nouvelles technologiques. Il est également possible de faire un bricolage s’il n’y a plus de maintenance. Mais, au bout d’un moment, tout peut s’écrouler qu’il faut tout reprendre à zéro. L’important est d’assurer que les applications soient toutes issues d’une même technologie. De plus, l’implication top management n’est pas un facteur nécessaire. C’est plutôt la maintenance qu’il faut prendre en compte. Les utilisateurs sont friands du changement en sphère privée, mais pas en entreprise, et cela se traduit par leur forte réticence au changement.
Interviewé 4
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Ma vision d’un système d’information est un outil qui permet à tous les individus d’accéder à l’information nécessaire à l’exercice de leurs fonctions. Un système performant doit être efficient tant en termes de réactivité que de consommation et intuitif.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Il est en constante évolution et parfois avec des mises à jour instables qui peuvent rendre un système inefficace pendant un laps de temps critique pour une entreprise. Il faut se tenir constamment à jour afin de pouvoir prévoir et répondre du mieux possible aux inconnus.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
L’obsolescence rend un logiciel ou un système incapable de remplir ses fonctions principales. On parle souvent d’obsolescence programmée pour les portables, les ordinateurs les machines à laver etc mais c’est aussi un gros problème pour les systèmes d’information.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
Justement au niveau des portables, des ordinateurs et des machines ménagères qui tombent généralement en panne juste après le délai de garantie. Au niveau professionnel ça peut aller de l’obsolescence d’un logiciel à l’obsolescence d’un projet ou programme lancé par des collègues.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
L’obsolescence est assez peu prise en compte car ils délèguent le problème aux équipes qui en ont conscience mais n’ont pas forcément tous les outils pour permettre d’y faire face. C’est un vrai problème de fond.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Lorsqu’il devient difficilement utilisable notamment au niveau de la sécurité informatique ou très simplement lorsqu’il n’est plus pris en charge par les mises à jour software. En ce qui me concerne, le département en cause est l’IT, cependant chaque service est censé remonté les informations à l’IT qui peut ensuite agir.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Les ingénieurs font en général remonter le problème au N+1 s’il n’en est pas informé et c’est ensuite lui qui va sonner l’alarme pour pouvoir faire face au problème.
Que faut-il faire pour mieux gérer cette obsolescence ?
Il faut mettre en place des SPO afin de minimiser la perte de temps et de ressources. Se faisant, le problème est remonté plus efficacement et les ressources sont mises en œuvre le plus vite possible pour faire face au problème.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Il faut éviter d’utiliser plusieurs logiciels utilisant plusieurs technologies différentes. Si possible, tout centraliser sous la même technologie par exemple avec les logiciels Microsoft. Ensuite, il faut tenir à jour le matériel tant d’un point de vue hardware que software en fournissant un support technique réactif et un matériel dernier cri.
Interviewé 5
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Alors selon moi un système d’information c’est l’ensemble des logiciels utilisés qui permettent de faire fonctionner dans mon cas l’entreprise. Ça va du CRM à l’ERP en passant par les boites mail etc. Il est performant tant qu’il remplit ses fonctions, après un système d’information est rarement efficient car il y a beaucoup de mises à jour et de changements à effectuer.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Il a beaucoup évolué ces dernières décennies avec des innovations majeurs quand on voit notamment ce qu’on peut faire aujourd’hui avec un ordinateur. Après aujourd’hui les innovations ont tendance à être minimes dans le sens où il y a peu d’innovations disruptives.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
Mon premier réflexe c’est de penser à l’obsolescence programmée de mon téléphone surtout les Apple. Ça m’est déjà arrivé qu’après une mise à jour le portable est des problèmes de batterie ou de réactivité qu’il n’avait pas avant.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
Bah la sphère privée comme j’en ai parlé juste avant surtout au niveau du téléphone, ça pose problème car c’est un gros budget. Après sur la sphère professionnelle ça m’est déjà arrivé d’avoir des problèmes de logiciel qui ne répondent plus et qui bloquent toute la production mais dans ces cas-là il y a toujours quelqu’un de disponible pour se déplacer et régler le problème le plus vite possible
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Oui comme je l’ai expliqué lorsqu’il y a une défaillance dans notre système, des experts sont joignables 24 heures sur 24 pour nous aider à régler le problème.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Un élément devient obsolète lorsque ses différents composants sont incapables d’assurer la pérennité du projet. Le département responsable est généralement celui qui est en charge du projet, mais c’est toujours sur le département informatique que la responsabilité retombe même si on n’en était pas informé.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
C’est surtout l’end user qui joue le rôle principal c’est-à-dire celui qui utilise le logiciel tous les jours dans ses tâches quotidiennes. Après le back office a généralement aussi sa part de responsabilité ainsi que le top management mais c’est à l’end user de faire remonter le problème.
Que faut-il faire pour mieux gérer cette obsolescence ?
Je dirai qu’il faut communiquer auprès de toutes les parties concernées de faire remonter les informations. Car il vaut mieux prévenir que guérir, le plus tôt on est averti d’un problème et le plus tôt il sera réglé et on pourra continuer à travailler.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Je pense qu’il faut réussir à rester à jour au niveau des innovations afin de toujours rester compétitif. Je veux dire par là qu’il faut avoir assez de moyens pour rester au top de la technologie et ne pas rester sur des modèles de projet archaïques qui ne supportent plus de MAJ ou qui « survivent » en attendant que les derniers utilisateurs passent à la version plus récente comme pour XP/Vista etc
Interviewé 6
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Un SI c’est pour moi tout un ensemble de composants avec l’infrastructure, les applications, les utilisateurs et l’administration. C’est un ensemble qui fonctionne ensemble, si un des composants est déficient alors l’ensemble des composants peut être mis en porte-à-faux.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
J’ai appris que le cycle de vie se décompose en quatre tâches :

La création de systèmes de manière évolutive et automatique
La prise en compte et le suivi des systèmes, souscriptions et ressources
La cohérence des systèmes durant tout le cycle de leur vie
La mise hors tension des ressources du système lorsqu’ils ne sont plus actifs

Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
L’obsolescence correspond à une incapacité d’un logiciel, d’un programme, d’un objet à remplir ses fonctions de base correctement. Pour moi une baisse drastique de performance correspond à de l’obsolescence même si le logiciel permet toujours de remplir ses fonctions car il ne permet plus d’atteindre ses objectifs dans les temps voulus.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
C’est souvent arrivé à des proches ou même à moi, avoir une machine à laver qui rend l’âme ou un téléphone qui ralentit énormément ce qui nous oblige à changer. Je trouve ça intéressant car c’est très flou, les entreprises provoquent-elles l’obsolescence pour justement vendre plus et augmenter leur chiffre d’affaires ? Ça sonne un peu complotiste mais ce serait logique en vrai.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Malheureusement non mais je comprends c’est aussi une question de budget, ils ne peuvent pas acheter de nouveaux ordinateurs ou des portables dès qu’une version plus récente sort. Après pour tout ce qui est obsolescence de logiciel c’est surtout nous l’IT on se débrouille pour rester au top tant qu’il n’y a pas besoin de payer des licences ou devoir demander au COMEX de prendre des décisions car c’est souvent trop long.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Alors il y a ceux qui considèrent qu’un projet est obsolète lorsque celui-ci est désormais hors tension, lorsqu’il ne permet plus de remplir ses fonctions de base mais moi je considère que c’est surtout lorsque le projet devient beaucoup moins efficient. Lorsque le temps de réaction est trop élevé et que ça devient vraiment « énervant » d’utiliser le logiciel. Ah bah c’est nous, c’est l’IT qui se « fait allumer » par tous les end-user lorsqu’un logiciel « déconne ».
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
C’est en général ceux qui font remonter le sujet au COMEX donc soit les end-user soit en général nous car les end-user viennent vers nous pour nous faire remonter le problème.
Que faut-il faire pour mieux gérer cette obsolescence ?
Je pense qu’il faut créer ou augmenter le budget alloué à l’obsolescence pour pouvoir avoir du matériel plus performant ou pouvoir acheter des licences de logiciel au top. Des formations aussi ça pourrait être pas mal pour pouvoir savoir quand il faut changer un ordinateur ou comment régler certains problèmes courants qui ne nécessitent pas de changer de machine.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Bah comme je l’ai dit, il faut former les salariés, peut être augmenté le budget pour le matériel car c’est très important. Je pense vraiment qu’il ne faut pas lésiner sur le matos car c’est ce qui fait perdre le plus de temps aux process. Si on doit choisir entre du matos de mauvaise qualité et pas cher et du matos de bonne qualité plus cher, il faut choisir la bonne qualité directe. Et c’est pas forcément nécessaire de choisir du Apple ou des trucs super cher mais en cherchant bien on peut trouver des produits de bonne qualité à un prix correct.

Interviewé 7

D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Un système d’information est un ensemble d’ensembles de données qui assurent l’atteinte des objectifs de l’entreprise. Les systèmes d’information ne sont pas des modèles indépendants de l’industrie informatique. Au contraire, un aspect clé de leur mise en œuvre réussie est leur intégration avec les données et les processus métier. Par conséquent, il est préférable de considérer les systèmes d’information comme des triangles. Les trois parties de ce triangle représentent les processus, les personnes et les ordinateurs. Pour réussir, un système d’information a besoin de chacun de ces composants pour fonctionner correctement.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Le processus comporte cinq étapes : la planification, l’analyse, la conception, la mise en œuvre et la maintenance.
Chaque étape doit être entièrement terminée avec succès avant que le SDLC puisse passer à l’étape suivante.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
L’obsolescence pour moi fait référence à la durée de vie ou à l’absence d’un actif. Lorsqu’un produit devient obsolète, il est considéré comme obsolète et inutile. C’est un gros problème pour les fabricants et les détaillants qui doivent la gérer du mieux possible.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
Dans la sphère privée, cela se manifeste notamment avec les produits technologiques du quotidien. Cela passe par la tablette, au pc et aux soi-disant smart Tv. Dans la sphère professionnelle me concernant ce se voit plus particulières sur les outils que j’utilise au quotidien.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Le risque d’obsolescence est un facteur qui affecte toutes les entreprises dans une certaine mesure et est un effet secondaire nécessaire d’une économie prospère et innovante. Ce risque entre en jeu, par exemple, lorsqu’une entreprise décide du montant à investir dans une nouvelle technologie. La technologie restera-t-elle suffisamment solide pour que l’investissement soit rentable ? Ou deviendra-t-il obsolète si rapidement que l’entreprise perdra de l’argent ? Je dirais que c’est pris en considération par les entreprises mais la réponse n’y est pas toujours.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Lorsque votre application est basée sur une technologie qui n’est pas à jour, intentionnellement ou non. En fait, les éditeurs peuvent décider de ne pas publier de nouvelles mises à jour de leur technologie pour diverses raisons.
Cela peut rapidement devenir un problème car votre application, qui a été développée avec une version spécifique de la technologie à un moment donné, pourrait prendre du retard si les mises à jour ne sont plus installées. Ce risque est encore plus grand si l’utilisation de l’application continue de bénéficier de périphériques nouvellement mis à jour, qui pourraient éventuellement ne plus être pris en charge. Assurément c’est à la DSI de prendre la décision ou non d’arrêter.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Pour moi, le Comité de Pilotage est l’une des instances de gouvernance chargée d’une part de faciliter l’intervention du commanditaire pour assurer les meilleures décisions et d’autre part d’établir l’état d’avancement du projet informatique. Il est garant de la cohérence entre les enjeux décisionnels et opérationnels et ainsi possède un rôle crucial dans la décision de l’obsolescence.
Que faut-il faire pour mieux gérer cette obsolescence ?
Quel que soit le domaine (informatique, électronique, logiciel…), l’obsolescence doit être prise en compte dès le début du processus d’achat et une stratégie pour vous protéger doit être élaborée. L’option la plus sûre est sans doute de s’abonner plutôt que d’acheter : un modèle d’abonnement mensuel permet d’externaliser le risque d’obsolescence tout en restant à la pointe de la technologie. Cette stratégie élimine également les coûts de remplacement. Le coût mensuel des matériaux s’intégrera naturellement dans le budget actuel sans les mauvaises surprises liées à l’obsolescence.
Il est aussi possible de choisir un fournisseur reconnu pour la flexibilité de ses solutions, notamment en matière de logiciels.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Les processus, les méthodes, les systèmes et les révisions devraient être quelque chose que l’on aime et qu’on ne craint pas, surtout pas quelque chose à ignorer et espérer qu’ils disparaissent. Tout programme qui gère de manière proactive la gestion opérationnelle de l’obsolescence est la marque d’un processus d’une gestion efficace et fluide.
Interviewé 8
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Les systèmes d’information sont des composants interdépendants qui fonctionnent ensemble pour collecter, traiter, stocker et diffuser des informations afin de soutenir la prise de décision, la coordination, le contrôle, l’analyse et les services dans une organisation.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Dans le domaine de l’ingénierie des systèmes, le cycle de vie d’un système est la vision d’un système ou d’un système proposé, couvrant toutes les phases de son existence, c’est-à-dire la conception, la conception et le développement, le système, la production et/ou la construction, la distribution, l’exploitation, la maintenance et soutien, déclassement, déclassement et élimination.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
Cela signifie lorsqu’un produit ou un service technique n’est plus nécessaire ou souhaité, même s’il peut encore être en état de marche. L’obsolescence se produit généralement lorsqu’un nouveau produit a été créé pour remplacer une version plus ancienne.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
L’obsolescence est de nos jours présente dans tous nos produits, que cela soit dans la vie professionnelle ou personnelle. Bien évidement cela passe par tous nos petits gadgets du quotidien qu’on doit par obligation changé régulièrement du justement à cette obsolescence.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Lorsque les industries à haute précision telles que le la mienne, le médical, l’industrie, le transport lourd, l’aérospatiale et la défense n’ont plus le volume d’achat ou le pouvoir d’achat qu’elles avaient autrefois, comment gérez-vous l’obsolescence de la gestion ? De toute évidence, lorsque les fabricants de puces décident d’arrêter de créer des gammes de produits pour le marché de la haute précision, les options sont limitées en raison de la faible utilisation par rapport aux autres gammes de produits.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Quand plusieurs facteurs affectent directement les coûts de maintenance. Il peut s’agir d’un développement et d’une évolution continue qui rendent laborieuse toute opération de maintenance, utilisant des techniques qui n’intéressent plus les développeurs ou accumulant les bugs.
Quoi qu’il en soit, il est préférable de comprendre l’investissement spécifique requis pour l’entretien et de se demander s’il est préférable de l’investir ailleurs.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
À mon sens, le chef de projet IT occupe un rôle crucial dans la décision de l’obsolescence. En effet il a une vision globale et pointue de ses sujets ainsi que des technologies utilisées. De ce fait, une meilleure prise de décision quant à l’obsolescence.
Que faut-il faire pour mieux gérer cette obsolescence ?
Si l’obsolescence est inévitable à long terme, tous les fabricants n’ont pas la même politique à cet égard. Afin de détecter le risque d’obsolescence associé à chaque fabricant, il est nécessaire d’interroger les personnes qui achètent le même produit. Une méthode simple, telle que la lecture d’avis en ligne, peut aider à éviter les erreurs d’achat.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Maintenir de bonnes relations et des lignes de communication ouvertes sont des aspects importants de toute entreprise prospère, mais encore plus lorsque les logiciels deviennent obsolètes. Si vous entretenez de bonnes relations avec le fabricant des logiciels que vous utilisez, il doit vous informer des avis de modification de produit, des avis de fin de vie /avis d’arrêt de produit et des achats de dernière minute une fois qu’il en prend connaissance, cela permet de se donner plus de temps pour se préparer.
Interviewé 9
D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Un système d’information est un ensemble complexe d’informations, de données et de processus interdépendants. Ils sont utilisés dans tous les aspects de la vie humaine, du commerce et de l’industrie.
La définition de système d’information en technologie est un terme large qui fait référence à tout système ou outil d’information qui facilite la collecte et l’utilisation de données. Les systèmes d’information peuvent être utilisés pour fournir un soutien dans une organisation, ainsi que pour un gain personnel.
En termes simples, un système d’information est un ensemble de méthodes et de techniques permettant de stocker, d’organiser, de gérer et de récupérer des informations sous forme numérique. Ils se présentent sous de nombreuses formes, telles que les ordinateurs, les appareils mobiles, les tablettes et les logiciels.
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Les éditeurs de logiciels utilisent la même approche, ils doivent fournir des systèmes plus généraux et personnalisables. Les systèmes organisationnels à grande échelle, tels que les systèmes d’entreprise, sont généralement développés et maintenus par le biais d’un processus systématique appelé cycle de vie du système, qui comprend six étapes : étude de faisabilité, analyse du système, conception du système, programmation et test, installation, exploitation et maintenance. .
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
Pour moi, l’obsolescence technique se produit lorsque le matériel et les logiciels sont remplacés par des versions plus avancées. Par exemple, lorsque les puces de processeur sont passées de 16 bits à 32 bits à 64 bits, le système d’exploitation a dû s’adapter à l’ancienne architecture.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
Je réagis souvent négativement à l’obsolescence et notamment à l’obsolescence programmée, surtout si les nouvelles générations de produits n’offrent pas d’améliorations suffisantes par rapport aux versions précédentes. Les marques comme Apple peuvent être ternies en stimulant artificiellement la demande par cette méthode, ce qui finit par faire fuir les consommateurs, moi compris.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Je pense que oui, car l’attente ne fait qu’amplifier la difficulté et le coût associés à la réponse. Les risques de sécurité informatique sont considérables.
Par conséquent, il est nécessaire d’avoir une politique proactive de recherche et de suppression des éléments obsolètes sans gêner les utilisateurs dans le processus.
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Il est par exemple nécessaire de suivre les tendances technologiques du marché. En d’autres termes, si vous êtes toujours ex exploitation d’un gros client et que votre principal concurrent a commencé à passer au SaaS depuis l’année dernière, vous êtes probablement en retard. Si vous ne voulez pas perdre de parts de marché, il est peut-être temps de repenser votre application. Cette décision doit se faire au niveau de la Direction des services informatiques.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Le responsable technique car il a pour mission de gérer la production et les aspects techniques du projet. Il reconnaît la faisabilité du projet d’un point de vue technique et détermine la meilleure manière de mettre en œuvre le projet en définissant chaque phase. Il est le garant de la qualité technique.
Que faut-il faire pour mieux gérer cette obsolescence ?
L’utilisation correcte des équipements peut effectivement retarder l’inévitable fin de vie. Afin de retarder les pannes, il est recommandé de partager les bonnes pratiques. Les cours de formation des employés peuvent décrire l’utilisation optimale d’une machine ou d’un système d’exploitation. Plus généralement, les compétences techniques sont les véritables leviers d’optimisation de la durée de vie des équipements.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Toutes les données collectées jusqu’à présent doivent être enregistrées et stockées en toute sécurité. Ces informations sont inestimables, et les rassembler dans un format facile à comprendre peut faire gagner un temps précieux en cas de casse. Cela ne signifie qu’il peut être nécessaire d’investir dans une base de données complexe

Interviewé 10

D’après vous, qu’est-ce qu’un système d’information ? Et à quel moment dit-on qu’il est performant ?
Les systèmes d’information, souvent abrégés en SI, sont l’ensemble des matériels, logiciels et réseaux de télécommunications que les gens construisent et utilisent pour collecter, traiter, créer et distribuer des données utiles. Ces données se trouvent généralement dans des environnements organisationnels, mais peuvent également exister dans des environnements personnels et domestiques.
Cette définition, ainsi que les nombreuses autres que l’on trouve sur Internet, se concentre sur deux éléments essentiels de la définition des systèmes d’information :
• Les composants du système d’information
• Le rôle que ces composants jouent dans une organisation
Que pouvez-vous dire concernant le rythme du cycle de vie du système d’information ?
Un cycle de vie système est une succession d’étapes vécues dans le développement d’un nouveau système d’information.
Si vous développez un système qui ne fonctionne pas correctement ou ne fonctionne pas exactement comme prévu, vous pouvez perdre beaucoup de temps et d’argent.
Si un nouveau système est soigneusement planifié et développé, il a plus de chances de réussir.
Quand on parle d’obsolescence, qu’est-ce que cela signifie pour vous ?
L’innovation technologique c’est bien n’est-ce pas ? Toutefois cela a aussi un côté sombre, lancer une musique effrayante. Si nous n’y sommes pas préparés, cela va sûrement faire des ravages dans notre vie et nos processus quotidiens. Non, nous ne parlons pas d’une prise de contrôle imminente par un robot. Pourtant, c’est un sujet qui mérite notre attention, voire notre inquiétude. On parle d’obsolescence technologique en milieu de travail.
À quel moment sentez-vous être confronté à ce problème d’obsolescence dans la sphère privée ? Dans la sphère professionnelle ?
En réalité, les mises à niveau n’ont pas besoin d’être aussi automatisées. Si nous suivons certaines bonnes pratiques de sécurité et contrôlons notre technologie personnelle, nous pouvons généralement les retarder. Après tout, il n’est pas réaliste pour tout le monde de se mettre à niveau du calendrier des entreprises technologiques – certains appareils, y compris les téléphones Android coûteux, ont cessé de se mettre à jour après seulement deux ans. Nous n’avons pas tous le temps ou l’argent pour acheter de nouveaux produits aussi régulièrement.
En même temps, nous ne voulons pas perpétuer nos gadgets afin qu’ils soient vulnérables aux bugs, cyber-attaques et autres failles. Pour ces raisons, des mises à jour logicielles sont souvent nécessaires. Tout le monde devrait pouvoir vivre et travailler en toute sécurité grâce à la technologie.
L’obsolescence est-elle un problème pris en considération par les entreprises ?
Les directions des systèmes d’information savent qu’il est relativement facile de remplacer du matériel ou des postes de travail, mais lorsqu’il s’agit de mettre à jour des logiciels ou des applications, l’opération est plus complexe et risquée. La plupart d’entre elles ont une mauvaise gestion de l’obsolescence dans leur système d’information
À quel moment dit-on qu’un élément d’un projet IT est obsolète ? Quel département est responsable de dire qu’il faut arrêter d’utiliser un outil obsolète ?
Au moment où l’application n’avait pas été pensée pour être évolutive. En effet, vous risquez de vous retrouver face à une application gelée et vous devrez migrer vers une autre architecture pour continuer à développer.
Il est de la responsabilité de l’architecte d’avoir une vision et de faciliter les mises à jour logicielles. De plus, de plus en plus d’architectes ne veulent plus se limiter à une seule plateforme.
Qui joue un rôle dans la décision de l’obsolescence dans le domaine d’un projet IT ?
Je pense que c’est un rôle qui incombe à la DSI car elle contrôle et pilote la gestion et l’optimisation de l’ensemble des systèmes d’information de l’entreprise pour servir au mieux sa stratégie de croissance.
Que faut-il faire pour mieux gérer cette obsolescence ?
Pour minimiser les risques d’obsolescence, la meilleure solution est d’organiser la transition vers une nouvelle génération de produits. Pour être prêt à tout moment, une solution as-a-service est souvent la meilleure option ! En choisissant de louer du matériel plutôt que de l’acheter, la flexibilité du modèle as-a-service protégé du risque d’obsolescence à long terme et garantit que le matériel est toujours à jour.
La problématique de ce travail est de savoir comment parvenir à une gestion optimale des risques d’obsolescence dans le cadre d’un projet IT. Quelles sont vos recommandations ?
Un élément clé de tout plan d’obsolescence consiste à revoir la feuille de route technologique. Cela permet aux équipes de développement d’identifier, d’évaluer et de sélectionner les technologies les moins susceptibles d’être affectées par l’obsolescence, et également de proposer des alternatives qui peuvent avoir des durées de vie plus longues. L’utilisation de cette technique peut également aider à planifier les mises à jour techniques pouvant être apportées aux équipements électroniques pendant la phase de “service”, réduisant ainsi le niveau de problèmes d’obsolescence.

besoin d’aide pour votre mémoire ? Contactez-nous!

rédacteur spécialisé

0 %

Plagiat

1 %

confidentiel

frais cachés

0 %

paiement sécurisé

Exemple de thèse professionnelle en Informatique

besoin d’aide pour votre mémoire ? Contactez-nous!

Tel:

Email:

Plan de site

Réseaux sociaux