Plus l'entropie [d'un] système est élevée, moins ses éléments sont ordonnés, liés entre eux, capables de produire des effets mécaniques, et plus grande est la part de l'énergie inutilisable pour l'obtention d'un travail, c'est-à-dire libérée de façon incohérente.
Notre travail d'ingénieur consiste à réduire localement l'entropie des systèmes. Si l'on ne comprend pas cela, on ne comprend rien au métier, et on a très certainement une productivité négative.
Bien sûr en tant qu'ingénieurs nous savons pertinemment que l'Entropie ne peut être réduite. Elle augmente. C'est une Loi de la Nature contre laquelle on ne peut rien. Mais cela n'est vrai qu'au niveau global. En tant qu'ingénieurs, nous savons bien que l'on peut remettre de l'ordre aux systèmes, les rendre plus efficients, réduire leur entropie, localement. En tant qu'ingénieurs, nous savons ou nous devrions savoir que cela n'a rien de naturel.
La Nature subit une entropie qui augmente. Les systèmes livrés à eux-mêmes également. Cas pratique :
Vous gérer un système. Il ne vous satisfait plus et vous souhaitez le remplacer par un nouveau. Vous êtes raisonnable, alors vous savez bien que l'ancien et le nouveau vont devoir cohabiter quelques temps, le temps de migrer les données et les processus de l'ancien vers le nouveau. Vous avez maintenant deux systèmes à gérer. Et vous aurez dorénavant deux systèmes à gérer. Vous ne vous débarrasserez jamais de l'ancien. Pourquoi ?
Tandis que vous êtes en transition, vous continuer à vivre, du moins je vous le souhaite. Puisque tous les processus et toutes les données ne sont pas encore passées au nouveau système, vous utilisez en partie l'ancien. Puisque vous utilisez l'ancien, vous l'alimentez. Il fait partie de votre écosystème. Il vit tant que vous vivez, et vice versa.
Puisque les deux systèmes cohabitent, ils doivent s'échanger des données. Ils doivent se connecter l'un à l'autre. Maintenant le nouveau dépend de l'ancien, et l'ancien du nouveau. Et vous ? Vous, vous devez jongler entre les deux, et ils ne fonctionnent pas pareil. S'ils fonctionnaient de la même manière, vous n'auriez pas eu besoin de changer, n'est-ce pas ? N'est-ce pas ?
Puisqu'ils ne fonctionnent pas pareil l'un et l'autre, tout ne peut être transmis de l'un à l'autre. Alors vous remarquez qu'une part non négligeable de vos processus dépend du fonctionnement non transmissible de l'ancien au nouveau. Alors ils vous faut changer, vous. Mais vous, vous ne vouliez changer que le système, pas vous-même. Vous, vous êtes raisonnable, vous n'êtes pas un de ces révolutionnaires qui veulent toujours tout changer !
Tant pis pour vous. Maintenant vous avez deux systèmes… et ils ne fonctionnent pas pareil.
Cette situation rend vos opérations compliquées, et vous avez du travail. Pour gagner du temps dans votre quotidien, vous finissez par mettre en place des scripts et des batchs afin d'aligner vos deux systèmes automatiquement. Ah ! On se sent mieux, pas vrai ? Vous avez le sentiment du travail bien fait, vous avez réduit la pression. Vous croyez avoir réduit l'entropie. Vous avez maintenant trois systèmes.
Vous avez maintenant produit une dépendance du nouveau système envers l'ancien, puisqu'il puise une partie de ses données et de son fonctionnement de celui-ci, via vos superbes rustines. Que la part migrable l'ait déjà été ou non, la migration en soi n'est pas achevée. L'ancien système est toujours là. La date de fin du projet est arrivée, et avec cela la fin des finances et du temps alloué. Si votre structure est petite, votre patron est parfaitement au courant du problème. Il vous dit tant pis, on fera avec nos deux systèmes en attendant de trouver une solution (il ignore le coup de la rustine). Si votre structure est grande, votre comité de direction est très fier de votre réussite. Il vous confie un nouveau projet de migration encore plus ambitieux.
Mes félicitations.