Péremption

Dans l’un de nos précédents numéros (9 septembre 2013), Daniel Lebeau, DSI de Glaxo Smithkline, nous a expliqué pourquoi les DSI doivent réduire la complexité d’un système d’information. Il serait intéressant de déterminer le point à partir duquel un système devient complexe au sens où l’on ne peut plus le maîtriser, par exemple l’interface de trop, l’interconnexion de trop, voire l’utilisateur de trop…

Ce point de non-retour doit bien exister, mais il est probablement invisible. Il existe bien sûr des méthodes pour déterminer de façon mathématique la complexité d’un système, par exemple les « graphes récursifs pondérés » (ne me demandez pas de vous expliquer le principe...). On aimerait ainsi disposer, comme pour les produits frais, d’une date de péremption qui préviendrait qu’au-delà de telle période le système d’information serait impropre à sa consommation. On pourrait bien sûr continuer à l’utiliser, à l’image des yaourts qui sont mangeables même après leur date de péremption...

Mais pas trop longtemps après, quand même ! Un système d’information « à consommer de préférence avant le... » serait ainsi un gage de qualité pour l’utilisateur (à supposer, bien sûr, comme pour les yaourts, que le produit soit fabriqué selon des normes de qualité). Cela permettrait à tous, développeurs, chefs de projets, utilisateurs, directions métiers et bien sûr aux DSI, de se rappeler en permanence qu’un système d’information est toujours périssable au sens usuel du terme : « Qui ne peut être conservé longtemps dans des circonstances normales sans s’altérer. »