Mes noces de rubis* avec la téléconduite.
* 35 ans au service de la téléconduite par Pascal Ordoquy
Le présent document n’a pas vocation à être porteur de doctrine ou d’une vérité révélée par une soudaine grâce informatique. Il est l’occasion, pour moi, de consigner par écrit quelques faits qui me sont apparus, en toute subjectivité, comme importants et méritant, à ce titre, d’être partagés. Chacun pourra le lire en fonction de sa propre expérience et y trouver, éventuellement, des pistes de risques à maîtriser, des idées pour conduire ses propres affaires. Ce document peut aussi être la source de désaccords dont je suis prêt à discuter.
J’ai donc examiné plusieurs points, listés ci-dessous, sans recherche d’exhaustivité ni de priorisation :
L’effet taille des bases de données
Le suivi d’un système complexe en exploitation
L’expression du besoin
L’expression claire d’un besoin est un facteur fondamental de la réussite pour tout projet. Pour autant, c’est un exercice extrêmement difficile à réaliser. Pour simplifier, mais aussi pour provoquer un peu j’ai distingué deux grands domaines :
le visible : C’est ce qui, en général, est ressenti comme l’expression du besoin métier par l’utilisateur. C’est le domaine dans lequel nous allons principalement retrouver les aspects fonctionnels.
le caché : c’est ce qui est exprimé de façon moins spontanées au niveau des phases de spécifications, par les exploitants métier, même si les conséquences ultérieures sont, elles, bien visibles du dit métier. C’est là où je classe pêle-mêle : les performances, la disponibilité, les régimes dégradés, la robustesse, l’exploitabilité, la gestion des données, l’évolutivité, la maintenabilité et la pérennité.
Le visible
Exprimer un besoin fonctionnel peut, a priori, sembler trivial pour quelqu’un d’un métier. Néanmoins, j’ai rencontré de nombreuses difficultés pour sa réalisation dans les différents projets auxquels j’ai participé, tant en réalisateur qu’en donneur d’ordres.
L’adhérence aux solutions existantes: Dans le cas d’un renouvellement partiel ou total, il est naturel et commode de s’appuyer sur les systèmes existants pour élaborer l’expression du besoin. Force a été de constater que souvent on essaye de décrire les fonctionnalités existantes, avec des améliorations éventuelles, en s’appuyant sur la réalisation de la fonction plus que sur son essence. Le risque est alors de considérer des habitudes (y compris de confort) ou des héritages d’un passé révolu comme de vrais besoins. En faisant ainsi, on remet rarement en œuvre une réelle analyse de la valeur et, de plus, on risque de manquer d’anticipation (cf. plus bas). Par ailleurs il est profitable d’effectuer une enquête, par des experts métier, sur les fonctionnalités des systèmes existants auprès des opérateurs eux-mêmes, en les faisant s’exprimer sur le pourquoi, sur les limitations et aussi sur les fonctionnalités non connues de leur part (et oui, cela existe).
La mode : les avancées technologiques ont permis de progresser fortement dans tous les domaines du SI et notamment dans celui des Interfaces Homme-Machine. Néanmoins, le look est quelquefois un piège dans lequel tout un chacun est tombé d’autant plus qu’il est séduisant (c’est le propre des artifices du diable… !). Prenons un exemple : Les menus déroulants sont très pratiques lors de choix limités, mais s’il s’agit de choisir un poste du réseau électrique français (parmi plus de 1000 occurrences), l’absence de pré-sélection par les premières lettres transforme la recherche en chemin de croix. Il importe donc de se mettre en situation d’exploitation pour juger de l’efficience dans la durée des réalisations au-delà de leur beauté et de leur séduction actuelle.
Le « perfectionnisme » : Un des défauts du monde de techniciens dans lequel j’ai vécu (et qui perdure peut-être), est, sans conteste, un penchant vers la complétude et l’exhaustivité au détriment de l’analyse de la valeur. Ainsi, l’énergie dépensée pour automatiser les quelques cas les plus atypiques s’est toujours montrée contre-productive :
o Elle alourdit les développements (et crée des écarts dans le cas d’utilisation de produits du marché,
o Elle alourdit les tests (de mise en production et de non régression), elle alourdit les montées de versions,
o Elle alourdit souvent la modélisation des données et donc la saisie (en augmentant, qui plus est, le risque de données erronées – les données devenant plus pointues et moins intuitives),
o Elle alourdit souvent aussi l’interface homme machine. Il faut toujours avoir présent à l’esprit qu’un cas particulier coûte quasiment autant en informatique que le cas général (et il y a un seul cas général). De plus, si on juge que les cas particuliers doivent faire l’objet de traitements automatisés, il est souvent préférable de les résoudre par m cas de glutes programmées que de chercher un modèle général incluant les particularités car, alors, ce sont tous les autres cas qui sont pénalisés.
Les écarts avec les produits : Il me semble aussi important de s’interroger lorsque les besoins que nous exprimons ne sont pas couverts par les produits du commerce ou ceux des fournisseurs spécialisés.
o Soit il s’agit de points stratégiques qui sont fondamentaux pour un leadership sur le domaine (par exemple, le réglage secondaire de tension) et il est alors préférable de les traiter par un système spécifique extérieur au système principal mais connecté via une interface la plus standard possible.
o Soit il est nécessaire d’en limiter le nombre au maximum.
Là encore, une analyse de valeur est fondamentale. Par ailleurs, un trop grand écart avec les produits des fournisseurs, joue un effet repoussoir pour les majors dudit domaine (dont les aspirations ne sont pas de faire des développements spécifiques) et donc de restreindre la concurrence. Le risque est aussi de disposer d’une sorte de produit hybride ayant à la fois les inconvénients des produits standards et ceux des produits spécifiques.
Trouver le bon niveau de détails des spécifications. Des spécifications imprécises se traduisent inéluctablement par des avenants avec les fournisseurs (et donc des coûts des délais, généralement non prévus (en volume)). Des spécifications trop précises, notamment lorsqu’elles visent à couvrir des fonctionnalités présentes dans des produits standards, coûtent chers, lors de l’élaboration, en matière grise, mais aussi en délais de réalisation (y compris les tests et la mise en service). Ce délai étant un risque de plus en plus important compte tenu de l’accélération des évolutions tant côté métier que côté technologies. Lors des MCO, Les ré-interrogations sur les besoins et les spécifications fonctionnelles des systèmes existants, à l’occasion de leurs évolutions pourraient permettre un lissage de charge et des transitions moins brutales.
Le caché
Si la rédaction des spécifications fonctionnelles est une tâche ardue, que dire de celles, souvent négligées, qui accompagnent l’environnement du système.
Les performances : j’ai rencontrés plusieurs écueils, lors de la définition des performances. Voici ceux qui me reviennent à l’esprit :
o Première difficulté : comment choisir un nombre raisonnable de chiffres pour définir (puis contrôler, et cela, à différentes étapes du cycle de vie) les performances d’un système. C’est une tâche délicate et d’un haut niveau d’expertise, qui n’est, malheureusement, pas toujours reconnue ni valorisée.
o Deuxième difficulté comment caractériser les conditions d’utilisations répondant aux niveaux de performances demandés (Régime nominal, régimes perturbés ainsi que les ampleurs et les types des dites perturbations (métier ou SI). Mon regret est de n’avoir ni assez instrumenté les systèmes existant, ni assez mis en place l’organisation nécessaire pour détecter, stocker et analyser les différentes situations. En général, on se préoccupe des situations incidentielles, en négligeant les situations chargées qui n’ont pas donné lieu à incident, ou pour lesquelles le fonctionnement n’a pas été trop affecté, vu de l’opérateur métier.
o Troisième niveau de difficultés, exprimer la volumétrie de la base de données associée aux exigences (quels sont notamment les paramètres les plus influant sur le comportement du système).
o Quatrième difficulté comment juger, lors des réponses des fournisseurs potentiels, la crédibilité des extrapolations effectuées par rapport aux systèmes existant ou aux maquettes réalisées. Le meilleur moyen de s’affranchir de cette difficulté reste bien de choisir des fournisseurs qui ont déjà réalisé des systèmes de dimensions a minima comparables.
o Cinquième difficulté, monter des scénarios de recette représentatif de ce que l’on veut tester en volumétrie, en activité. Par exemple, j’ai été piégé par les caches-mémoire, certains automates de scénarios effectuant des actions certes nombreuses mais sur un nombre limité d’éléments, introduisaient un biais dans les mesures, car les éléments concernés finissaient par être pré-chargés dans les caches-mémoire réduisant ainsi de façon drastique, mais de façon illusoire, les temps de réponse. Il est donc nécessaire de consacrer à la fois une expertise de bon niveau et des moyens suffisants pour concevoir et réaliser ou faire réaliser les scénarios ad hoc. Cet investissement, même s’il paraît lourd sera globalement une source d’économie lors du bilan final.
La disponibilité. Son objectif est difficile à exprimer par les utilisateurs. Un pourcentage global est trompeur, des durées et fréquences d’indisponibilité sont plus aisées à comprendre. Par exemple un taux de disponibilité de 99,9% ne signifie pas grand-chose en soi : Vaut-il mieux avoir 3 pannes de 3 heures ou 90 pannes de 6 mn dans une année ? Il faut pourtant prendre parti, car les solutions pour faire face ne sont pas du tout les mêmes et n’ont donc pas les mêmes conséquences en termes de coût ou de management. Si 90 pannes de 6 mn sont jugées inacceptables, le doublement avec reprise automatique s’impose et il faudra investir (temps de mise au point et conditions techniques permettant la reprise rapide par ex fonctionnement en parallèle) fortement sur cet aspect. On pourra peut-être faire l’économie d’une organisation humaine redondante. Si, au contraire, c’est la panne de longue durée qui est jugée inacceptable il faudra mettre en place une organisation humaine (astreinte, exploitation décentralisée dans d’autres sites, etc…) pour y faire face.
De même le calcul prévisionnel de la disponibilité est quelque part un peu illusoire : Si les pannes matérielles peuvent être estimées, les pannes logicielles n’ont jamais fait l’objet d’une approche indiscutable et sont souvent sous-estimées, voire omises. Ceci peut être d’autant plus gênant qu’elles peuvent être la cause de pannes de modes communs… la même configuration de données aberrantes traitée au même instant par deux logiciels identiques permissifs sur deux machines distinctes conduit à 2 plantages quasi simultanés avec le meilleur système doublé qui soit. Quoiqu’il en soit on sait que le doublement de système améliore fortement la disponibilité. Il en est de même pour le raccourcissement des délais d’interventions qui, en contrepartie, a un fort impact sur les coûts d’exploitation.
Les calculs de fiabilité montrent aisément que la disponibilité pourrait être améliorée par le triplement d’équipements indépendants, or, des modes communs (notamment logiciels mais aussi alimentation, climatisation et même interventions manuelles inappropriées de l’exploitant du système) existent dont la probabilité d’occurrence est souvent supérieure à celle des pannes d’un système doublé. Par ailleurs, la réalisation de logiques de commutation très performantes (reprise à chaud instantanée, choix d’un élément parmi N avec N> 2) conduit à une amélioration de la disponibilité au quotidien mais à une aggravation des pannes graves et/ou complexes. Ce phénomène est similaire aux bouclages des réseaux HT sous la THT qui améliorent la permanence de la fourniture, mais peuvent être la cause d’effondrement de parties de réseaux… Néanmoins, ces obstacles ne sont pas une raison pour ne rien faire ! Il est fondamental pour les systèmes critiques de faire une étude de type sûreté de fonctionnement. Cette étude, même si elle ne donne pas une vision parfaite et absolue, permet d’une part de faire des comparaisons en valeur relative entre des solutions comportant des niveaux de redondances comparables et d’autre part d’apporter une vision anticipatrice sur un certain nombre de points faibles.
En général, plus c’est simple et plus c’est fiable, en contradiction avec la logique bien connue des Shadocks : « pourquoi faire simple, quand on peut faire compliqué », logique dans laquelle, nous, et moi le premier, sommes parfois tombés.
Les régimes dégradés : la définition de régimes dégradés permettant une exploitation des fonctions vitales est un complément à la disponibilité qui n’est que très rarement utilisé, mais qui oblige à hiérarchiser les besoins et donc de mieux définir architectures et parties de logiciel à durcir. Ceci permet aussi une contractualisation plus précise de la maintenance des logiciels. En exploitation, la difficulté supplémentaire réside dans la mise en œuvre de gestes rarement exécutés et dans des situations tendues au niveau exploitation métier et, quelquefois aussi, au niveau du relationnel.
L’exploitabilité : C’est aussi un des parents pauvres de l’expression des besoins. Sa prise en compte permet une meilleure surveillance préventive des systèmes, mais aussi permet à minima de mieux définir les gestes complexes et/ou risqués de l’exploitation (changement de versions de bases de données, de versions de logiciels, restauration suite à problème….) et de proposer des procédures ad hoc. L’utilisation de produits d’exploitation, qui se répandent sur le marché est à examiner. Le choix est alors très important, certains produits très puissants peuvent se révéler complexes à gérer et contre-productifs, l’homogénéité du parc d’outils est également à prendre en compte…
La gestion des données de configuration : la qualité d’un système en exploitation est conditionnée par celle de son maillon le plus faible. Pour les systèmes comportant de nombreuses données le système de configuration est souvent un talon d’Achille. Au-delà d’une souplesse raisonnable des outils de configuration, l’utilisation de standards pour l’export et/ou l’import de données est primordiale, ainsi que les possibilités d’une certaine automaticité d’opérations répétitives. Par ailleurs, la traçabilité des gestes effectués est un plus pour détecter a posteriori, puis corriger les gestes inappropriés.
La robustesse : C’est une façon plus illustrée de prendre en compte la fiabilité d’ensemble. Un système peut en effet être très disponible s’il a un nombre significatif de pannes (globale ou partielle), mais que celles-ci sont très vite réparées. Un système non robuste, s’il est fiable, peut néanmoins être excessivement pénalisant s’il connaît des plantages sur des fonctions critiques (blocage de télécommande, basculement lors d’avalanches d’informations, figeages de process). Les critères de robustesse d’un système sont délicats à définir, et encore plus à tester dans les phases de recettes, où l’activité du système n’est jamais totalement représentative d’une activité réelle.
Dans les grands systèmes qu’il m’a été donné de suivre, nous avons toujours rencontrés en premier les problèmes fonctionnels. Lorsque ce premier type de problèmes est globalement résolu, et que l’on pense avoir fait une grande part du chemin, restent un certain nombre de problèmes liés aux performances. Ces problèmes sont plus difficiles à régler que les problèmes fonctionnels. De plus les solutions trouvées peuvent induire des évolutions de la modélisation des données et se traduire par la création de nouveaux problèmes fonctionnels et de problèmes de performances dans d’autres parties de l’applicatif. Quand les problèmes de performances ont été résolus, ou que des compromis judicieux ont été trouvés, alors les problèmes de robustesse deviennent plus visibles. Apparaissant comme plus aléatoire, ils sont plus difficiles à piéger, à expliquer et bien sûr à corriger, avec le même type d’effet de bord que précédemment.
L’évolutivité, la maintenabilité, la pérennité.
Ces points contribuent, bien évidemment à une bonne gestion patrimoniale et sont dans les souhaits du commanditaire et de la maîtrise d’œuvre.
Mais au-delà, des grands principes, de nombreux écueils guettent les projets.
o L’évolutivité fonctionnelle : une ouverture non ciblée n’est pas spécifiable, donc difficilement appréciable et encore moins recettable. De plus, si le fournisseur essaye d’y répondre honnêtement, il engagera des coûts qui le desserviront au niveau de la consultation. Enfin la complexification d’un système pour un futur hypothétique est un risque pour le développement du système souhaité. Il faut donc disposer d’un minimum de directions des évolutions fonctionnelles pour limiter ce risque et faire un audit de l’architecture et de ses points faibles. Une autre solution est d’utiliser des produits du marché, mais de renoncer ainsi à être un des précurseurs dans le domaine concerné, sauf à développer des solutions innovantes externes au système fournisseur en attendant que le marché se mette à niveau.
o La maintenabilité : Il est sain de penser qu’un système bien conçu et réalisé selon les règles de l’art sera plus maintenable qu’un autre. Si cette condition semble incontournable (encore que difficilement mesurable dans une consultation) dans un produit réalisé sur mesure, elle est loin d’être suffisante dans tous les cas. La maintenabilité passe souvent par la pérennité de la société en charge du produit mais peut-être plus encore de sa politique industrielle. Dans le cas de marché de niche (ce qui est souvent le cas pour la téléconduite, mais moins fréquent pour les télécommunications, sauf aux interfaces avec le réseaux électrique), les stratégies des groupes industriels (rachats et/ou filialisation) peuvent compromettre les espoirs de pérennité des solutions acquises, ou de maintenabilité à des coûts raisonnables. Le client, en la matière, n’a que des mauvaises solutions à sa disposition :
* Ou bien, il contractualise avec le fournisseur une maintenance de qualité sur le long terme, mais qui sera d’autant plus chère que les exigences en réactivité et en maintien des compétences seront élevées. Dans ce cas, les leviers de contrôle habituellement mis en œuvre (pénalités) ont une efficacité toute relative et risque de conduire à une sous-évaluation des risques encourus par le système.
* Ou bien, il assume lui-même la maintenance avec ses propres équipes. Ceci de mieux maîtriser le turn-over au rythme de la montée en compétences mais présente l’inconvénient de créer une filière technique très étroite au sein de laquelle il faudra prévoir des évolutions de carrière semblables à celles des autres filières et/ou des passerelles efficaces avec elles.
Evolutions de la technologie. Les évolutions rapides des technologies bouleversent la pérennité des applications. Je pense que nous ne reverrons plus d’applicatifs ayant des durées de vie comme celles du SGEP, du SIRC ou d’OCCITANE. Il est donc illusoire de prévoir une évolutivité et une pérennisation couvrant des périodes d’une vingtaine d’années et ce, malgré le coût des renouvellements.
D’où la nécessité de raccourcir les temps de développement de nouveaux systèmes et donc l’intérêt :
* De pouvoir récupérer les données du système N-1 pour peupler le système N ou de pouvoir peupler le système N à partir de sources externes.
* De pouvoir plugger des satellites accueillant nos spécificités.
* De dimensionner les équipes RTE pour réduire les délais, tout en sachant que même, avec neuf femmes, on ne fait pas un bébé en un mois.
De plus on se trouve de plus en plus « prisonnier » d’ensembles de fonctionnalités très riches dont la maîtrise n’est pas toujours évidente, notamment en termes de sécurité. Il faut donc exercer une veille très vigilante sur l’évolution des produits du marché et estimer en permanence les opportunités de changement de palier techno (ex : passage à Unix, dos, ios, android ? etc… )
L’effet taille
Un raisonnement simpliste, mais néanmoins assez ancré dans l’inconscient collectif, pourrait laisser croire que la taille d’un système n’est que l’affaire de puissance de traitement des machines. J’ai appris, à mes dépends, que cela n’était, malheureusement, pas aussi simple. La taille (et ce concept serait d’ailleurs à définir plus précisément) joue sur un certain nombre d’aspects notamment les suivants :
Performances : Il est évident que les performances sont fonction de la taille des systèmes. La charge résultant de la taille t du système est plus difficile à appréhender. Elle peut être proportionnelle à t, à t*log(t), a t2 ou plus. Elle peut aussi connaître des courbes de saturation et devenir exponentielle au de la d’une taille critique. Il est donc problématique d’évaluer les performances d’un système n’existant pas ou existant, mais dont la taille serait trop différente de celle recherchée. La détermination des temps de réponse est encore plus complexe à établir.
Impacts sur le fonctionnel : S’il est bien un domaine où l’on pourrait penser qu’il y a indépendance avec la taille, c’est celui du fonctionnel. Néanmoins il peut y avoir des interactions non négligeables, notamment avec l’ergonomie. Prenons quelques exemples pour illustrer le problème. Les menus déroulants : pour un système comportant une cinquantaine de postes électrique un menu déroulant pour la liste des postes est adapté, mais que penser du choix dans une liste de 2000 postes, s’il n’y a pas en plus une aide (prise en compte des premiers caractères saisis…). Même problème pour l’accès aux postes électriques depuis une image globale unique. La taille pose le problème de la conception, de la réalisation et de la navigation (temps et localisation) dans une telle image. Le problème a été rencontré aussi sur des listes d’alarme. La différenciation des niveaux d’alarmes par la seule couleur est acceptable sur un système de faible taille, mais devient dangereuse lorsqu’un incident survient sur un système de grande taille, où l’opérateur doit faire défiler ses pages d’alarmes pour connaître les événements importants en cours.
La mise à jour des données. Plus la taille d’un système, plus le nombre de données à y intégrer croît, et, de ce fait, la multiplication des intervenants croit et, par voie de conséquence, la nécessité de renforcer l’organisation au niveau de la saisie et des contrôles se renforce. Il s’agit donc de mettre en place une véritable administration des données. Par ailleurs la volumétrie peut amener à une certaine taylorisation des tâches et de ce fait à un affaiblissement de la vision globale et/ou à un risque sur la détection des «cas particuliers » et donc à des risques d’erreurs accrus, alors même que les données sont souvent le talon d’Achille de tous les systèmes. Le plus beau des systèmes au niveau conception, réalisation et maintenance peut s’effondrer par des saisies de données inappropriées. On pourrait rappeler qu’une des deux raisons qui ont amené à ne pas reconduire le système expert mis en place pour diagnostiquer les incidents réseau dans le CRC a été sa fragilité vis-à-vis de l’exactitude à mettre à jour, en permanence, les données sur les protections des ouvrages du réseau. En conclusion, plus la taille des données croît, plus les contrôles automatiques doivent être renforcés et plus l’organisation doit être adaptée pour bien traiter d’une part l’expertise pointue nécessaire pour maîtriser une administration complexe au niveau volumétrie et SI ainsi que d’autre part les tâches de fond qui peuvent se révéler fastidieuses compte tenu de la volumétrie.
La réactivité dans la mise à jour : Le fait d’avoir des données qui suivent au plus près l’évolution des modifications sur le terrain est un facteur important vis-à-vis de la sûreté du système (ne serait-ce que pour les contrôles de télécommande). D’autre part la même sûreté impose que les évolutions des bases de données soient sûres et donnent lieu à des contrôles performants. Une des façons de résoudre cette antinomie est de préparer des lots d’évolutions des données et de les mettre en service le moment venu. L’augmentation de la taille des réseaux pris en compte a un impact sur le processus. Sur un grand réseau, le nombre d’évolutions quasi simultanées amène à prévoir des lots comportant un nombre d’évolutions importants et donc sensibles aux aléas (retards, d’un lot, changement de priorités, difficultés de consignations…)
La mise au point, les tests : La définition et la réalisation des tests se complexifie avec la taille. Simulation de plus de éléments, de plus d’opérateurs et donc de possibilités d’interactions entre opérateurs… Phénomènes d’avalanches plus longs à mettre en œuvre… sont des points qui se conçoivent assez naturellement. Par contre lors de la mise au point initiale ou celles d’évolutions importantes, il peut arriver que des reprises de modélisation de la base soient nécessaires. Dans ce cas, la taille de la base de données peut devenir pénalisante pour les coûts et les délais lors de sa mise à niveau..
L’anticipation
Côté technologie
Le positionnement par rapport aux évolutions de la technologie est, de façon générale, un problème délicat. Il l’est encore plus sur des systèmes sur lesquels repose la sûreté du système électrique. Le fait d’utiliser des systèmes non matures est un risque important, le fait d’utiliser des systèmes bien éprouvés, pose le problème de la durée de vie de systèmes en général long à développer. Par ailleurs, j’ai constaté une évolution depuis une trentaine d’années. Autrefois les technologies utilisées étaient plutôt des technologies de faible ou moyenne diffusion, appuyées sur des constructions intellectuelles poussées. De nos jours, les technologies « grand public » ont un tel effet d’entraînement qu’elles ont fait sauter la majorité des certitudes qu’avaient les gourous du passé : « Il n’y aura de téléconduite sous Unix, sous Windows, il n’y aura d’échanges de téléconduite sous TCP-IP etc… »
Cet envahissement de la téléconduite par le « grand public » présente plusieurs inconvénients avec lesquels il faut s’accommoder.
Manque de visibilité : Les évolutions technologiques étant poussées par les marchés « grand public », la visibilité sur les trajectoires est faible car les sociétés qui innovent fortement protègent la vision de leurs inventions pour bénéficier de la primauté et de la surprise.
Volatilité plus grande des logiciels : Je ne prendrais comme exemple que la vitesse de parution des OS Microsoft, sur lesquels tournent pourtant les postes opérateurs des dispatchers… Cette volatilité pose le problème des stratégies de portabilité. On reste au même niveau, mais on est rattrapé par l’obsolescence des matériels supports ou on suit les évolutions des logiciels et on a à supporter à la fois les coûts, les perturbations et les risques de ces évolutions. Par ailleurs ces évolutions sur des ensembles de matériels et de logiciels n’est pas sans poser des problèmes d’interfonctionnement (voire même de fonctionnement).
Frustration des utilisateurs : Ne pouvant suivre la cadence des IHM des outils « grand public » on crée une frustration parmi les utilisateurs qui comprennent difficilement pourquoi le système sur lequel ils travaillent est beaucoup moins souple que les logiciels qu’ils ont chez eux… et qui sont souvent plus ludiques !
Côté métier
Evolution des métiers. Même si les métiers tournant autour de la conduite et des télécommunications ont été moins bouleversés ces dernières années que d’autre domaines tels que le domaine « marché » suite aux directives européennes, ou au domaine finance-RH suite à l’indépendance par rapport au SI d’EDF, une inflexion assez forte a été ressentie ces dernières années. Alors que dans les années soixante-dix, les évolutions étaient largement à la main du management d’EDF, le futur est maintenant beaucoup plus tributaire de l’extérieur de l’entreprise. Quel sera le rôle des dispatchings nationaux par rapport à un centre européen ? Quels peuvent être les futures exigences européennes ? Celles de la CRE ? La difficulté est donc de concilier ces incertitudes à moyen et long terme avec des temps de réalisation de systèmes, dont il est exigé qu’ils soient sûrs, et, dont les expériences récentes en France et à l’étranger montrent qu’ils sont longs à réaliser de par leur complexité (exemple centre de conduite) ou de par leur étendue (réseau de téléconduite).
Métier et SI. Les possibilités d’automatisation qu’offre le SI sont vues comme une opportunité pour améliorer les contrôles au cours des processus, et comme une aide complémentaire pour les opérateurs. Plusieurs expériences m’ont conforté dans le fait que cette démarche pouvait être contre-productive. L’introduction d’une plus grande rigidité, en effet, si elle n’a pas été accompagnée par une démarche managériale forte, et par un réel dialogue entre les parties prenantes se traduit par un rejet en bloc du système informatiques et des concepts supportés. Pour les projets majeurs, il me fondamental de travailler sur les impacts organisationnels, ceux affectant les gestes au quotidien et sur les aspects psychologiques (exemple : transferts implicites de tâches entre différentes catégories de personnel ou impression d’un tel transfert). Sans anticipation, le meilleur SI complexifie plus les situations qu’il n’aide à les résoudre.
L’effet parc installé
Avoir un parc installé important présente des avantages non-négligeables. Je citerai par exemple, la mutualisation des coûts de développement, le poids économique et l’attrait vis-à-vis des fournisseurs, l’assainissement plus rapide des logiciels (en matière de bugs). Mais elle présente aussi des inconvénients :
Compatibilité : Trois périodes différentes sont impactées par le problème de la compatibilité.
* Le déploiement d’un nouveau palier. En téléconduite, il n’est pas possible, dans l’état actuel de l’état du marché, de déployer en masse et rapidement, comme pour la bureautique. Les raisons tiennent principalement dans la nécessiter de valider préalablement les données de façon fine. Compte tenu des impératifs de sûreté du système électrique, cette validation nécessite à la fois du temps compte tenu du nombre important d’informations, du besoin en compétences spécifiques (en nombre limité) et de l’impact sur l’exploitation (qui impose de mener un nombre limité de validations en simultanéité). Tant que cette durée ne pourra être sensiblement réduite, les déploiements s’étendront sur des périodes longues par rapport à la durée de vie des matériels, voire des logiciels supports. Les solutions mises en œuvre jusqu’à présents ont consisté à pré acheter des lots complets en anticipation (avec les risque associés) ou à effectuer des mises à niveau intermédiaires, avec des retrofits.
* Au niveau de maintien en conditions opérationnelles, cela pose le problème des lots de maintenance à créer, et/ou des versions logicielles adaptées à plusieurs paliers matériels-logiciels à gérer.
* Au niveau du développement : les temps de développement étant généralement étendus, les logiciels support et les matériels sont déjà hors catalogue à la recette opérationnelle du produit. A ma connaissance, aucun contrat initial n’a prévu, dans le marché initial, le portage nécessaire sur les versions catalogue des produits au moment de la mise en service, sachant que cette dernière proposition renvoie le risque sur le fournisseur, qui se couvrira au niveau des coûts, mais toutefois, dans le cadre de la consultation où il est en concurrence.
Politique d’évolution : petits pas ou grands sauts. : Faut-il faire des évolutions régulières ou des chambardements de temps en temps. Cette question se pose pour tous les systèmes (évolution des matériels, des logiciels supports, politique des progiciels …) mais elle devient beaucoup plus délicate avec la taille des systèmes (coûts, délais, risques), et je pense qu’il n’existe pas de solution universelle. Il importe d’avoir une ligne directrice claire et de s’y maintenir sans faire de zapping aux premiers aléas. Il est néanmoins nécessaire de réexaminer en profondeur la stratégie avec une certaine périodicité pour éviter d’arriver à un point où on est victime du syndrome du bûcheron…. qui est le suivant : Un bûcheron coupe du bois pour l’hiver avec une hache émoussée. Un passant lui fait remarquer qu’il devrait affûter sa hache pour être plus efficace, et le bûcheron répond : « je n’ai pas le temps, j’ai du bois à couper ».
La difficulté du suivi à bon niveau
J’ai ressenti principalement deux phases pendant lesquelles le positionnement du suivi pouvait poser problème.
* La phase de réalisation : Pour les projets d’une certaine taille et donc d’une certaine durée, les relations avec le fournisseur peuvent se traduire :
o Soit par une exaspération réciproque et une glissade du gagnant-gagnant au perdant-perdant et des ancrages sur des interprétations différentes du contrat (ce qui est toujours possible, quel que soit le soin apporté à sa rédaction). Cette situation est exacerbée quand les spécifications fonctionnelles continuent à évoluer lors de la réalisation du projet.
o Soit par une sorte d’aveuglement, qui entraîne les deux parties à vouloir persévérer dans la poursuite de la solution initiale, alors qu’une remise en cause partielle ou totale serait préférable.
Il importe donc de prévoir, pour les grands projets, un acteur (ou un groupe sous la responsabilité d’un acteur) qui ait l’implication nécessaire pour consacrer le temps et l’énergie nécessaire, mais suffisamment de recul, en étant dégagé du quotidien, avec un réel pouvoir d’arbitrage pour prendre ou faire prendre les décisions ad hoc. On pourrait, dans certains cas, aussi penser aux nouvelles approches de réalisation rapide, pilotées par ce qui reste possible à faire dans les délais impartis.
* La phase d’exploitation. Toute phase d’exploitation connaît des dysfonctionnements. Parfois (et c’est le cas souhaitable) les limites de ceux-ci sont définis aussi précisément que possible dans les contrats. Néanmoins, ces bilans ne doivent pas rester de simples bilans comptables et doivent être analysé avec du recul. Il me semble important de voir les tendances, analyser les corrélations entre les actions et les résultats, examiner l’ensemble sur des périodes où un lissage permet d’éliminer les coïncidences fortuites et également d’éviter de céder à une panique néfaste en cas de pannes rapprochées. La synthèse est donc difficile à effectuer entre le recul qui assure le filtrage et la réactivité qui permet de prévenir la répétition de pannes semblables.
La difficulté à capitaliser
J’ai rencontré deux types de difficultés principales dans la capitalisation des expériences :
* La traçabilité du besoin. Dans la majorité des cas, la spécification de la réalisation initiale est conservée, elle n’est pas toujours tenue à jour lors des évolutions ultérieures. La traçabilité du besoin et de son contexte est, plus rarement exprimée et encore moins conservée et mise à jour. A fortiori, les choix écartés et les raisons pour lesquels ils l’ont été, ne sont qu’exceptionnellement tracés et conservés. De plus, il existe des cas où, malgré l’existante d’une traçabilité, celle-ci n’as pas été exploitée par le projet suivant.
Sur un autre plan, j’ai pu constater l’efficacité technique et commerciale, de la séparation entre
o La présentation du contexte, les exemples, l’illustration du besoin.
o La formulation des exigences et de leur repérage sans équivoque.
* La transmission de l’expérience. Une part non négligeable de spécificités au sein des projets SI a quelques fois amené le pilotage des projets à plus s’appuyer sur des expériences personnelles dans d’autres domaines et à négliger de tirer les leçons des retours d’expérience des projets SI passés, dont il faut le reconnaître, le niveau de synthèse devrait être amélioré.
