Le second principe s’applique aux données

Définition de l'entropie d'information

En thermodynamique, l’entropie est une mesure du désordre présent au sein d’un système. En théorie de l’information, l’entropie mesure la quantité de données qu’il faut pour décrire une situation. En d’autre terme, plus une situation est compliquée, plus sa description est longue et son entropie élevée. A l’inverse, plus une situation est simple et ordonnée, plus sa description sera succincte et plus l’entropie sera faible.
Imaginons que vous deviez décrire une forêt contenant dix mille arbres. Si c’est une forêt sauvage, vous devrez décrire la position, l’essence, la taille et le diamètre de chaque arbre, soit pour faire simple 5x10000 = 50000 informations élémentaires (décrire un arbre est bien sûr plus complexe … c’est une première approximation). A l’inverse, si c’est une plantation d’arbres, tous de la même essence, plantés en même temps, et sur un plan de carré planté à intervalle régulier, il suffit de connaître le diamètre, la taille, l’essence d’un seul arbre et la position de deux arbres situés à deux coins opposés du carré pour décrire totalement la situation, soit 7 informations élémentaires. L’entropie représente donc en quelque sorte la complexité d’une situation.
Cette dernière définition de l’entropie peut tout à fait s’appliquer à un système d’information. En particulier on peut l’appliquer aux données contenues dans ce système.

Exemple de la saisie de données

Je vous suggère de mener une petite expérience pour appréhender la notion d’entropie des données. Demandez à une population de nombreuses personnes de remplir un formulaire (informatique ou non d’ailleurs …). Par exemple, demander leur de remplir leur nom dans une case. Vous constaterez invariablement que les gens ne vont pas tous remplir leur nom de la même manière. Certains vont écrire leur nom de famille, d’autre leur nom et leur prénom, d’autres encore leur prénom puis leur nom. Certains vont préciser Monsieur, Madame, ou Mademoiselle devant, en variant les abréviations. La plupart vont écrire leur nom de famille avec une première lettre en majuscule, d’autres vont l’écrire entièrement en majuscule. Pareil pour le prénom. Si vous augmentez la population, vous en trouverez certains qui plus curieusement laissent tout en minuscule. Et je ne parle même pas des coquilles.
C’est un peu facile, puisque l’on n’a pas été précis sur la manière de remplir le formulaire. Mais si vous recommencez l’expérience avec des instructions précises, le résultat sera certes plus homogène, mais vous aurez quand même de nombreuses variantes. Certaines personnes n’auront pas ou mal compris vos instructions, d’autres se tromperont, d’autres enfin ne les respecteront tout simplement pas par défi ou incurie. Pour ma part, après avoir tenté cette expérience dans de nombreuses circonstances, je ne suis jamais parvenu à obtenir un résultat parfait, quel que soit le degré de précision des instructions fournies, même si le résultat s’améliore globalement avec des instructions précises. J’ai même constaté que si l’on cherche à être trop précis, ceci devient contre productif, les gens ne lisant même pas les instructions jusqu’au bout, découragés par leur caractère trop complexe et pointilleux.

Exemple des doublons

Un autre exemple classique d’entropie est la création de doublons dans une base de données. Par doublon, j’entends deux données représentant le même objet physique. Ceci se produit par exemple pour les personnes dans les réseaux sociaux. J’ai environ une centaine de contacts sur des réseaux sociaux professionnels tels LinkedIn ou autre. Sur ces 100 contacts, j’ai eu au moins 3 personnes qui se sont en fait créé deux profils par erreurs, et qui ont ensuite toutes les peines du monde à gérer leurs comptes. Elles ne l’ont bien sûr pas fait sciemment, mais à des moments différents. Sur quelques millions d’inscrits, cela fait quelques dizaines de milliers de doublons.
Il n’est pas toujours possible de détruire ces données ou de les fusionner car certaines données ne sont pas effacées physiquement et les procédures de fusion inexistantes. Elles restent donc au mieux masquées et désactivées.

Exemple du recyclage d’identifiants

Dans une base de données des articles vendus chez un distributeur, sur un ancien système informatique, la limite logique du nombre d’article était à 100000. Ceci paraissait élevé au début de l’exploitation, mais 20 ou 30 ans plus tard, de tels systèmes sont en pénurie chronique d’identifiants. Ceci amène à gérer les codes disponibles comme une ressource rare, et à les recycler. Souvent, les systèmes n’ont pas été prévus pour cela et des résidus des anciennes données se télescopent avec des nouvelles sur les codes recyclés. Tel le chiffre d’affaire d’un yaourt à la fraise X du début de l’année cumulé au chiffre d’affaire d’un dentifrice Z à la fin de l’année … drôle de mélange !
Ce n’est pas pour rien que l’on utilise aujourd’hui des numéros de séquences incrémentaux et non recyclable pour gérer ce genre de problème.

Exemple du détournement de champs

Un autre cas de désordre apparait quand les utilisateurs détournent consciemment ou non le sens des champs d’une application. Par exemple, dans une base prévoyant « titre » (Mr, Mme, Mlle, Mr ou Mme, etc.), « nom de famille » et « prénom », on a retrouvé pour la plupart des entrées la concaténation des 3 champs dans le nom de famille. « Mademoiselle Catherine Martin » se retrouvait dans le champ « nom de famille » et les champs « titre » et « prénom » restaient vierges. Impossible ensuite d’accéder simplement aux noms de famille dans la base …

Caractère normal de l'augmentation

Bien sûr ces exemples sont loin de faire le tour de la question, et il serait vain de faire un inventaire des situations chaotiques que nous rencontrons dans les systèmes d’informations. Je les ai tous rencontrés à titre personnel, et à plusieurs occasions. Et j’avais en général beaucoup de difficultés à faire comprendre aux intéressés en quoi leur comportement était problématique.
Le second principe de la thermodynamique précise qu’un système voit spontanément son entropie augmenter. Les exemples précédents vous auront convaincu je pense qu’il en va de même pour l’entropie des données dans les systèmes d’information.
Les exemples donnés montrent comment elle apparait spontanément et croît avec le nombre d’utilisateurs et le temps :

• un utilisateur n’applique pas toujours la même règle pour saisir les données à des moments différents
• plusieurs utilisateurs ont a priori des comportements différents, même si les instructions sont précises et claires
• les utilisateurs ont une probabilité non nulle de se tromper à chaque saisie et ne vérifie pas en général ce qu’ils écrivent

Pourquoi les développements sont plus longs que prévu ?

Il est bien connu que les projets informatiques ne respectent pratiquement jamais leurs délais. La loi de Hofstadter indique non sans humour :

« Une tâche prends toujours plus de temps que prévu, même si vous prenez en compte cette loi ».

Plusieurs des lois de Golub reviennent aussi sur ce phénomène:

« Aucun grand projet informatique n'est jamais mis en place dans les délais, dans les limites du budget, avec le même personnel qu'au départ, et le projet ne fait pas ce qu'il est censé faire non plus. Il est fort improbable que le nôtre soit le premier. »

« Un projet mal planifié prendra trois fois plus de temps que prévu. Un projet bien planifié prendra seulement deux fois plus de temps. »

Une fois la satisfaction de l’ironie, du cynisme et de l’autodérision passée, la vraie question à se poser est : pourquoi ?

Même si les chefs de projets rejettent en général la faute de ces dérives sur les dépendances externes, ou sur les modifications demandées en court de route par le client, il faut aussi admettre qu’une des causes principales est la mauvaise estimation des délais nécessaires aux tâches de programmation. Dans un récent article, j’ai lu une explication que j’ai trouvée un peu rapide, et qui m’a amené à réfléchir aux nombreux cas que j’ai dû traiter avec des équipes projets en difficulté.

En effet, il est vain de chercher une explication générale, car de très nombreux phénomènes sont à l’œuvre pour induire ces retards :

• La perspective : de même qu’une montagne lointaine parait petite, une tâche éloignée parait plus simple, car on n’en voit pas tous les détails. Quand on estime une tâche, on fait une simulation mentale de ce qu’il y aura à faire. On ne rentre pas dans les tous les détails car sinon, cela revient à pratiquement à la réaliser complètement d’avance. Donc par conséquent, si on s’en tient aux charges imaginées, on en néglige nécessairement une partie …
• La sous-estimation par fierté: les développeurs technophiles sont en général très optimistes sur leur capacité de réalisation des développements informatiques. Ils sont très fiers de leurs connaissances et de leur capacités, se croient en général plus compétents que leurs collègues et donc sous-estiment chroniquement le temps qu’il leur faut pour réaliser une tâche. Si la tâche est estimée par eux, et réalisée par leurs collègues, la dérive dans le temps de la réalisation les conforte dans leur croyance de supériorité. Ceci relativise d’ailleurs les techniques d’estimation collective comme le poker planning de scrum si les groupes impliqués sont trop marqués par cette tendance.
• « Cà va marcher du premier coup ». Les tâches de développement ont cette particularité qu’elles ne sont finies que quand le programme fonctionne. Il faut donc aménager du temps dans l’estimation pour vérifier que le résultat produit par le développement est conforme à ce qui est attendu (les tests unitaires). Or il est très difficile dans certains cas de prévoir combien de fois il faudra revenir sur le programme et refaire le test pour qu’il finisse par marcher, ou combien d’effort il faudra pour corriger certains problèmes. Face à cette difficulté, la tendance est d’imaginer que le développement marchera du premier coup, ce qui est bien sûr faux en moyenne.
• Le peaufinage. Comme ils prennent du plaisir à programmer et aiment leur métier, certains développeurs ne voient pas le temps passer, s’intéressent à des détails peu importants, refont plusieurs fois une partie de code pour parvenir à un résultat parfait, bref dépassent allègrement leur estimation initiale, mais bien sûr pour d’excellentes raisons …
• La loi de Parkinson, qui stipule que
  

  « le travail s’étale de façon à occuper le temps disponible pour son achèvement. »

  En effet, la tendance naturelle face à une situation confortable est de prendre son temps, de ralentir en quelque sorte suffisamment pour vérifier la prédiction. Toute tâche remplit donc au minimum le temps prévu initialement. Ceci annihile toute chance de rattrapage des dérives calendaires d’un projet par des tâches surestimées et explique pourquoi les provisions de délais ou les marges sont systématiquement consommées.
• La procrastination, c'est-à-dire la propension à remettre systématiquement au lendemain les tâches difficiles. Ceci se produit quand les tâches élémentaires sont trop longues, ce qui amène le développeur à pouvoir choisir par quoi il va commencer. La tendance naturelle sera alors de repousser les tâches apparemment plus complexes à la fin, pour commencer par les plus simples. Ceci n’est pas forcément conscient, et s’apparente à un déni : la peur d’affronter une tâche difficile crée une angoisse, et c’est bien le report le plus tard possible qui permet de l’oublier un temps pour la contrôler. L’estimation du reste à faire s’en trouve faussée, car au début le développeur accordera faussement à la tâche repoussée la même difficulté que les autres, et les tâches simples avanceront à un bon rythme. Ce n’est qu’en approchant de l’échéance qu’ils reprendront conscience du problème et que l’angoisse renaîtra. Le reste à faire remontera donc, mais trop tard pour pouvoir réagir.
• Une variante de ce phénomène est la dissimulation: les développeurs peuvent rester bloqués sur un problème sans le signaler. Soit par timidité, soit par peur de critiques. Ils préfèrent parfois attendre le moment où il est évident qu’ils n’auront pas fini à temps pour le signaler. Ce problème est typique des situations de management où les gens sont jugés uniquement sur le résultat et non sur la méthode employée pour y parvenir, ce qui arrive quand le chef ne comprend pas le travail concret de ses subordonnés.

Et cette liste n’est sûrement pas exhaustive... Les deux derniers points expliquent d'ailleurs une autre des exagérations humoristiques des lois de Golub :

« Les projets progressent rapidement jusqu'à 90%, puis ils restent achevés à 90% pour toujours. »

Il n’est donc pas surprenant que les projets ne soient pas à l’heure. Ce qui est surprenant, c’est quand le contraire arrive parfois … Peut-être que certains chefs de projet ont trouvé des solutions à tous ces problèmes ?