Comment faire perdre beaucoup d'argent à son entreprise.

GBPost est une entreprise qui propose un service d'envoi de courriers postaux. Les clients envoient des courriers via Internet. Un petit logiciel réceptionne le courrier via une interface WEB, il traite le courrier (ajout d'images et conversion de format), puis il le transmet à un système spécialisé qui imprime le courrier, et le place dans une enveloppe libellée à l'adresse du destinataire.

Le petit logiciel intermédiaire qui réceptionne le courrier via une interface WEB, qui le traite, et qui le transmet au système d'impression pose quelques problèmes. Ce petit logiciel, qui est en fait un service WEB (sous Apache) est écrit en Perl, sous Linux.

L'entreprise demande à ses ingénieurs de faire une étude pour déterminer les causes des problèmes. Dans le rapport des ingénieurs on peut lire la chose suivante :



La conclusion du rapport, ainsi que les préconisations des ingénieurs, est le signe d'une grande incompétence qui va faire perdre beaucoup d'argent à leur employeur!

Prenons les points du rapport un par un :

(1) L'utilisation du langage Perl est la source du problème. C'est totalement faux.

(2) Le langage C++ est préconisé. C'est une aberration technique et financière.

(3) L'usage des threads est préconisé. C'est une aberration technique et financière.



L'utilisation du langage Perl est la source du problème : C'est faux.

Prenons une analogie avec les travaux publics :



Tout le monde est d'accord avec l'exemple ci-dessus. Et bien en informatique, c'est la même chose...

Ce qui fait la différence, en terme de qualité logicielle, c'est avant toute chose l'architecture et le savoir-faire des développeurs.

(*) Prenez des bons développeurs expérimentés. Ils produiront du bon code, quel que soit le langage.

(*) Prenez des mauvais développeurs... Ils produiront du mauvais code quel que soit le langage utilisé.

La qualité du code dépend infiniment plus de son organisation et de son niveau de documentation, que du langage utilisé.

(*) Le langage Perl ne produit pas du code illisible... comme on l'entend dire de la bouche de personnes incompétentes. C'est le développeur qui produit du code illisible (pas le langage utilisé).

(*) Il ne viendrait à l'esprit de personne de dire que l'utilisation de la langue française produit un message incompréhensible. Pourtant, il y a des gens qui parlent français mais que l'on a de la peine à comprendre...

(*) Les langages de programmation, comme les langues sont des outils pour s'exprimer. Soit, on sait utiliser correctement ces outils, soit, on ne sait pas. Mais l'outil n'est pas en cause. C'est l'utilisateur de l'outil qui est en cause.

Le choix d'un langage plutôt qu'un dépend surtout des facteurs suivants :

(*) Le logiciel doit-il être utilisé dans un contexte temps-réel? Ce contexte implique une très grande réactivité. Un langage de programmation qui produit un binaire directement exécuté par le processeur est indiqué. Typiquement : C, C++.

(*) Le logiciel doit-il être utilisé dans des applications qui mettent la vie d'êtres humains en jeu? Un langage de programmation qui produit un binaire directement exécuté par le processeur est indiqué. Typiquement : C, C++, ADA. Le fait que le code s'exécute directement par le processeur réduit les "intermédiaires" (interpréteurs ou machines virtuelles). En limitant le nombre d'intermédiaires, on réduit les risques.

(*) Le logiciel doit-il être utilisé dans un environnement caractérisé par des quantités de ressources très réduites? Un langage qui permet un contrôle très fin des opérations est indiqué. typiquement : C ou assembleur.

(*) Le logiciel constitue-t-il un "socle" pour d'autres applications? Autrement dit : Le logiciel assure-t-il une fonction spécialisée, largement utilisée par d'autres applications? Dans ce cas il est justifié d'optimiser au maximum le logiciel. Typiquement : C, C++. C'est très coûteux, mais le prix est justifié.

(*) Le logiciel n'a pas besoin de présenter une grande vitesse d'exécution (pour diverses raisons). Une des raisons peut être, par exemple, qu'une grande vitesse ne pourrait, de toute façon, jamais être atteinte à cause des contraintes de l'environnement. La fonction assurée par le logiciel ne met pas la vie d'êtres humains en jeu. Et la fonction de ce logiciel n'est pas utilisée par d'autres applications... Les langages "interprétés" (Perl, Pyhon, PHP, Java, C#,...) sont tout indiqués. Le développement initial, et la maintenance, sont grandement facilités. Le coût du logiciel est alors beaucoup plus bas que s'il était développé avec des langages "bas-niveau" (typiquement C, C++).

(*) Le système d'exploitation utilisé : Sous Windows, on utilisera plus PowerShell ou C#. Sous UNIX, on utilisera plus Perl, PHP, Python ou Java.

(*) La culture d'entreprise : Perl, PHP et Pyhton sont grossièrement équivalents. Le choix se fera par rapport à la culture d'entreprise...

(*) Le coût (et le temps) : Si vous avez de l'argent à dépenser, et du temps à perdre, alors je vous conseille de tout développer en C ou en C++.

Mais tous les langages modernes habituellement utilisés sont fiables. Les langages suivants sont fiables, et ils disposent de tous les outils nécessaires pour écrire de code de qualité : C, C++, Perl, PHP, Python, C#, TCL, ADA, Pascal, Java,...

(*) L'envoi de courrier n'est pas une fonctionnalité qui met la vie d'êtres humains en jeu.

(*) Le logiciel d'envoi de courrier n'est pas largement utilisé par d'autres applications.

(*) La performance, en terme de vitesse, de l'outil n'est pas un critère de choix. Nous verrons que, de toutes façons, même si nous développons un bolide, ce dernier ne pourra par rouler à sa vitesse maximum.

(*) L'entreprise doit économiser de l'argent et réduire la durée de développement.

(*) Le logiciel tourne sous UNIX.

(*) Les langages interprétés, disponibles sous UNIX (Perl, PHP, Python), sont tous fiables et disposent tous d'une grande trousse à outils, qui couvre tous les besoins.

Conclusion : L'utilisation d'un langage interprété, tel que Perl, est indiquée. C'est une solution économique, mais tout aussi performante, qu'une solution plus onéreuse.





Le langage C++ est préconisé. C'est une aberration technique et financière.

Quel est l'avantage du C++ par rapport aux langages interprétés?

(*) Le C++ produit du code directement exécuté par le processeur. Le code d'un langage interprété est exécuté par un interpréteur, qui, lui-même est exécuté par le processeur. L'intermédiaire entre le code et le processeur réduit les performances en vitesse. Il augmente aussi les possibilités de survenue d'une erreur...

(*) L'augmentation du risque d'erreur est extrêmement faible, car tous les langages sont fiables. Ce point n'est valable que pour des applications "critiques" pour lesquelles une défaillance aboutirait à une catastrophe. Typiquement : Centrale nucléaire, avion,... Dans le cas d'un banal outil d'envoi de courrier, ce point n'a strictement aucune importance. Il ne justifie en rien l'utilisation du C++.

La réduction des performances en vitesses pourrait éventuellement être invoquée. Et certains pourraient être tentés d'y apporter un crédit. Mais ce serait méconnaître l'environnement dans lequel s'exécute le logiciel : un système d'information. Dans ces conditions, l'architecture joue un rôle infiniment plus important que le choix du langage pour ce qui est des performances! Dans ce cas d'utilisation, c'est l'architecture qui fait la différence, pas le langage.

Quels sont les inconvénients du C++ par rapport aux langages interprétés?

(*) Le nombre de lignes de code C++ est sans commune mesure avec celui d'un langage interprété. On peut, sans trop de risque de se tromper, affirmer qu'un programme écrit en C++ comporte au moins 10 fois plus de lignes de code qu'un programme écrit dans un langage interprété. Cela rallonge considérablement les temps de développement et le risque d'erreur.

(*) Les interpréteurs se chargent de tout un tas de tâches délicates qui sont la source de très nombreux problèmes. En C++, vous devez tout gérer vous-même... Cela augmente considérablement les risques d'erreur et le temps de mise au point.

(*) Les interfaces des "trousses à outils" (librairies) disponibles en C++ sont très souvent beaucoup plus délicates à utiliser que celles fournies pour les langages interprétés. Cela augmente considérablement les risques d'erreur et le temps de mise au point.

(*) Un développeur C++ coûte beaucoup plus cher qu'un développeur dans un langage interprété.

Bref, un développement en C++ coûte beaucoup plus cher. Le coût initial est plus cher, et la maintenance est plus chère.

Donc, s'il n'y a pas une très bonne raison pour utiliser le C++, il vaut mieux l'éviter!

Pour quelle raison l'argument de la vitesse d'exécution n'est pas valable dans le contexte de l'outil d'envoi de courrier?

Toute la "vélocité" procurée par le C++ n'est qu'une illusion. En effet, cette vélocité ne pourrait pas s'exprimer. Pour faire comprendre ce point, je prendrais une analogie avec la vie réelle :



Le système d'information d'une entreprise comme GBPost est comparable à un environnement urbain. Ce n'est d'ailleurs pas un hasard si l'on parle "d'urbanisme des systèmes d'information.

L'utilisation du langage C++ n'apporte absolument aucun avantage. Au contraire, il n'apporte que des inconvénients techniques. Et il représente une perte financière sèche : On dépense beaucoup pour rien... absolument rien.

(*) Le coût de développement initial est colossal en regard de celui lié à l'utilisation de langages interprétés.

(*) Le coût de développement lié à la maintenance est colossal en regard de celui lié à l'utilisation de langages interprétés.

Et tout ça pour rien! Bref, d'un point de vue financier, il s'agit du plus mauvais choix qui soit.

Conclusion : L'usage du C++ est une aberration. Son utilisation n'apporte que des inconvénients. Il s'agit d'une perte financière sèche.

En revanche, ce qui est rentable, c'est la connaissance du terrain. Il faut s'appuyer sur le terrain pour gagner du temps.
Dans un système d'information, on a l'habitude d'utiliser des serveurs WEB Apache. Ils sont fiables, bien connus...
Les systèmes d'exploitations utilisés pour héberger les systèmes d'information disposent d'un tas d'outils conçus pour faciliter la vie : Il s'agit des langages interprétés. Ils sont fiables, optimisés... Ils ont été conçus pour faire gagner du temps. Ils sont associés à des trousses à outils qui couvrent tous les besoins courants. Ils ne coûtent rien. Ils font économisez de l'argent tout en produisant un résultat tout aussi fiable.

Il existe un autre argument en faveur de l'utilisation d'un langage interprété telle que Perl. Cet argument repose sur la nature du processus d'envoi, ainsi que sur une propriété des trousses à outils des langages interprétés.

D'un point de vue macroscopique, le traitement d'un courrier est une suite d'opérations macroscopiques spécialisées, qui ne peuvent être exécutées que l'une après l'autre. Typiquement, avant d'envoyer le courrier, il faut l'imprimer. Avant de l'imprimer, il est indispensable d'avoir construit le document... Il n'est pas possible d'envoyer un courrier par "petits morceaux".

C'est là qu'il faut se pencher sur les outils présents dans les trousses à outils des langages interprétés :

Ces outils sont spécialisés dans l'exécution d'une tâche spécifique. Ces outils sont en général extrêmement performants pour la tâche pour laquelle ils sont destinés. Prenons, par exemple, l'outil ImageMagick. Cet outil permet de manipuler des images. Cet outil est présent dans les trousses à outils de pratiquement tous les langages couramment utilisés (Perl, PHP, Python, C; C++,...). Mais les interfaces associées aux langages interprétés (Perl, PHP, Python) sont beaucoup plus simples que celles des langages compilés (C, C++). En revanche la puissance de l'outil est la même quelque soit le langage à partir duquel il est utilisé : Il s'agit du même outil, ce n'est que l'interface qui change. Que vous utilisiez ImageMagick en Perl ou en C++... cela ne change absolument rien aux performance de l'outil ImageMagick.

Autrement dit :

Ce qui différencie l'usage d'un même outil à partir d'un langage ou d'un autre, c'est uniquement l'interface utilisée pour contrôler l'outil. Les interfaces associées à un langage interprété (Perl, PHP, Python) sont en général beaucoup plus simples à utiliser que celles associées à un langage "bas-niveau" (C, C++). Et cette simplification de l'interface ne s'accompagne pas d'une dégradation de performance. Le bénéfice est évident.

Dans ces conditions, la stratégie la plus adaptée est évidente : On choisit un langage interprété qui ne fait que commander des outils spécialisés et hautement performants (qui font partie de la trousse à outils du langage). Le langage interprété joue le rôle de manager qui délègue l'exécution des tâches spécialisées à ses équipes. Le bénéfice est évident : Abaissement des coûts, par rapport à l'utilisation d'un langage "bas-niveau", pour des performances égales.

Pour illustrer ce point de vue, nous allons prendre une analogie issue de la vie courante :



(*) Un logiciel bien conçu utilise intelligemment les outils de sa trousse à outils.



L'usage des threads est préconisé. C'est une aberration technique et financière.

D'une façon générale :

(*) Sous un environnement UNIX, la tradition est d'utiliser des processus, et non des threads, pour implémenter des exécutions parallèles de "tâches".

(*) Sous Windows, c'est l'inverse : Sous Windows, la tradition est d'utiliser des threads, plutôt que des processus.

La "tradition" s'explique de façon extrêmement simple :

(*) UNIX a été conçu, dès le départ, comme un environnement qui permet d'exécuter plusieurs tâches en parallèle. Autrement dit, UNIX a été conçu, dès le départ, comme un système d'exploitation multitâche. Une tâche est associée à un processus.

(*) Windows est dérivé de DOS (qui est un système d'exploitation mono-tâche : DOS ne peut exécuter qu'une seule tâche à la fois). Windows est donc conçu, à la base, sur un système d'exploitation mono-tâche. Pour simuler le multitâche, les concepteurs des premières versions de Windows ont créé les threads : Ce sont des fonctions qui s'exécutent, "en parallèle", au sein d'un même processus.

Donc, pour résumer :

(*) UNIX est conçu, architecturé et optimisé, pour l'exécution simultanée de processus. Aussi, lorsque l'on "pense multitâche" sous UNIX, on pense d'abord à l'utilisation de processus.

(*) Windows est "conçu", architecturé et optimisé, pour l'exécution de threads (au sein de processus). Aussi, lorsque l'on "pense multitâche" sous Windows, on pense d'abord à l'utilisation de threads.

Il existe des implémentations des threads pour UNIX. Sous UNIX, l'utilisation de threads, ou de processus, pour implémenter du multitâche, peut sembler équivalente. Mais ce n'est pas le cas : Les deux techniques ne sont pas interchangeables. Le choix d'une technique, plutôt que d'une autre, dépend de critères précis.

Et, surtout, sous UNIX, le choix de l'utilisation des threads n'est pas anodin : L'utilisation des threads sous UNIX est très délicate (ce n'est pas le cas sous Windows). Il faut être extrêmement prudent. Si l'on peut se passer des threads, alors il ne faut pas hésiter. Mais, surtout, si l'utilisation des threads n'est pas justifiée, alors il ne faut surtout pas les utiliser. Typiquement, si le problème est de gérer des exécutions parallèles de tâches indépendantes les unes des autres, l'utilisation des processus est bien préférable à l'utilisation des threads (sous UNIX, je le répète) : Le développement est beaucoup plus simple, plus rapide, et donc, moins coûteux.

Typiquement, sous UNIX, l'utilisation des threads est justifiée dans le cas d'une tâche qui peut être "parallélisée", et pour laquelle la parallélisation apporte un réel avantage, en terme de temps d'exécution. Ces critères sont associés à certaines propriétés :

(*) "Couplage" fort entre les entités de traitement. Autrement dit : Forte utilisation de "données partagées" et "synchronisation élaborée". Cela signifie que les entités qui s'exécutent en parallèle travaillent sur la même information, en même temps, et de façon fortement synchronisée.

(*) Le temps d'exécution lié aux entées/sorties est négligeable par rapport au temps de calcul. Si le nombre d'entrée sortie est important, le gain, en durée, apporté par l'utilisation des threads est tellement insignifiant que leur utilisation n'est pas justifiée, en regard de la complexité de programmation qu'ils impliquent.

L'exemple typique est celui du calcul matriciel (ou d'autres calculs mathématiques) :

(*) L'importance des données partagées (la matrice) est importante.

(*) Il n'y a pas d'entrées/sorties.

(*) Et, surtout, l'algorithme se prête bien à la parallélisation, dans la mesure où il est possible de calculer la matrice par "petits bouts", en même temps. La logique de calcul n'impose pas un traitement séquentiel.

L'envoi d'un courrier est une tâche macroscopiquement séquentielle. Et le traitement de la lettre "A" est "sémantiquement" indépendant de celui de la lettre "B". La mise en forme de la lettre "A" n'a aucune raison de dépendre du contenu de la lettre "B". Autrement dit, les processus de traitement ne partagent pas d'information.

Note : La seule partie du traitement qui bénéficie d'un traitement parallèle est la phase de traitement de l'image... Mais cette tâche est prise en charge par un outil spécialisé (en l'occurence, ImageMagick).

Conclusion :

Dans le cas particulier de l'envoi de courriers, l'utilisation des threads n'est absolument pas justifiée. Leur utilisation engendre une complexité (importante) supplémentaire inutile.

(*) Cette complexité rallonge les délais du développement initial.

(*) Cette complexité rallonge les délais des développements liés à de la maintenance évolutive.

(*) Cette complexité augmente le risque de voir apparaître des problèmes.

(*) Bref, cette complexité augmente inutilement le coût du projet.

C'est tellement vrai! Vous savez, on constate ce genre d'aberration dans toutes les entreprises! On signe des contrats aberrants partout.

Bravo! C'est le plus bel exposé qui m'ait été fait! Heliopsis, êtes-vous disponible?

Nombreuses sont les SSIIs qui essaient d'arnaquer le client - au maximum. On vend des prestations aberrantes, à des prix aberrants. On maquille les CVs... Et il y a toujours des pigeons qui se font avoir.

Votre analyse est extrêmement pertinente : les décideurs font souvent des choix rationnellement aberrants

Je pense pour ma part que le décideur n'a pas un rapport rationnel avec l'outil informatique. Dans la sphère des "personnes autorisées", qui "s'autorisent à décider", c'est l'émotionnel, et la pensée magique, qui règne en maître.

Le décideur a peur. Il a besoin d'être rassuré. Oh! il ne va pas voir le marabout du coin! Au lieu de cela, il va consulter le commercial de service... Il se jette dans la gueule du loup!

Le Chacal

Les entreprises ne vendent que ce qu'elles maîtrisent. Dans le cas contraire, soit la technologie n'est pas la meilleure car on ne la maîtrise pas, soit ce n'est pas la tendance du moment et l'on a du mal à trouver les bonnes personnes pour l'implémenter.