Des enseignements pour aujourd’hui ?

Les techniques informatiques ont profondément évolué depuis 40 ans, et il est évident qu’on n’aborde plus aujourd’hui leur enseignement comme on le faisait dans les écoles des années 1970. Les concepts se sont enrichis, les méthodes de développement des logiciels ont beaucoup évolué, au point que certaines qui prévalaient au siècle dernier sont maintenant considérées comme obsolètes. Les ressources en télécommunications et en capacité de stockage de l’information ne sont plus, ou sont beaucoup moins des contraintes pour le programmeur.

Pourtant, certains principes demeurent, et il parait important de les repérer.

L’approche systémique

On emploie souvent le terme « système informatique » pour désigner un ensemble d’équipements numériques qui concourent à la réalisation d’une fonction. Mais il ne faut jamais oublier de considérer le contexte dans lequel il se place, en y incluant notamment les opérateurs humains. Le système informatique n’est jamais qu’une partie de cet ensemble qu’il faut regarder dans sa globalité.
C’est ce qui a conduit les concepteurs de SDART à faire convenablement la part de ce qui peut être automatisé et de ce qui doit rester du ressort de l’opérateur humain. L’automatisation n’est pas une fin en soi. Elle ne doit servir qu’à faciliter le fonctionnement global d’un système dans des conditions technico-économiques aussi proche que possible de l’optimum, l’homme étant inclus dans l’analyse.

Oublier ce principe peut conduire à concevoir des systèmes automatiques trop sophistiqués, risquant d’échapper au contrôle ou de ne pas apporter les réponses appropriées face à des séquences d’événements inattendues. Nous avons connu dans le passé des tentations de ce type, où une trop grande sophistication a conduit à un résultat finalement très éloigné de l’objectif initial, avec notamment une dégradation du retour sur investissement.

L’effet changement de génération

L’évolution très rapide des techniques pose inévitablement la question de l’obsolescence des équipements. Quand doit-on passer d’une génération à une autre ? Une politique de palier technique doit être élaborée en évitant, d’un côté, l’effet « zapping » consistant à prendre en compte la moindre nouveauté et, de l’autre côté, le maintien dangereux d’un palier obsolescent.
Cet arbitrage est délicat, et l’expérience montre qu’il n’y a pas de règle simple pour l’établir. Ce qui compte, c’est de poser périodiquement la question, et d’arbitrer en fonction des conditions du moment, sans chercher à reproduire des raisonnements qui ont pu se justifier à une époque précédente.

Les changements de génération sont des décisions difficiles à prendre car le retour sur investissement est difficile à évaluer. Tout l’art consiste à ne pas dépasser un certain seuil, au-delà duquel les coûts de maintenance dus à l’obsolescence croissent très vite.

La conduite des projets et la tenue des délais

La tenue des délais est une difficulté récurrente de tout projet, et particulièrement des projets à forte composante informatique.
Cette difficulté n’est pourtant pas une fatalité, à condition de savoir la traiter avec sérieux et une ténacité de tous les instants, dans le cadre d’une conduite de projet rigoureuse, partagée par tous les acteurs, avec un responsable unique clairement mandaté.

L’importance des essais

L’une des raisons pour lesquelles le SDART a pu avoir des difficultés de tenue des délais tient en la gestion des essais. Les plannings initiaux ne tenaient pas suffisamment compte des temps nécessaires aux tests, car on avait sous-estimé leur importance. Force a été de reconnaitre que ces essais sont à la fois nécessaires et couteux en temps. Il n’existe pas de programme logiciel qui fonctionne bien du premier coup. Les essais doivent être pris en compte à toutes les phases du processus de développement d’un système informatique. Celui-ci doit être outillé pour permettre ces essais dès l’amont du processus. Plus tard les erreurs sont détectées et plus elles coutent en correction.