Discussion :

[louxorman]

Salut, sauf erreur de lecture de ma part il n'est pas précisé à quel périmètre géographique se rapportent ces statistiques.

[SurferIX]

Je suis content que Python gagne du terrain dans le monde Pro, je me suis spécialisé dans ce langage depuis déjà quelques années et je regrette pas.

3 fois plus de "down" que de "up" dès que tu dis que Python est un bon language... décidément je ne sais pas pourquoi les Français sont des Python - haters !

[LEKHEBASSENE]

Il aurait été intéressant d'avoir en complément des informations croisées sur le types de projets : application de gestion, supervision, workflow, sites web, jeux, calcul scientifique, simulation, logiciel de communication, interfaces graphiques, web services, migration de données ... Je pense que ça ne sera qu'à partir de là que nous aurons un corpus d'information intéressant, car certains langages ont des avantages sur certains cas d'usage.

Il est vrai que Java est un langage quasi-universel : systèmes embarqués, web, application d’entreprise, application mobiles, systèmes de communication, DAB, puces ... avec les avantages de la portabilité, une pléthore de bibliothèques une énorme communauté, l'existence d' IDE hyper-structurés et ouverts, des cadriciels (frameworks) stables, matures. Ces facteurs étant des facteurs de cercle vertueux qu'aucun autre langage n'a su réunir et qui explique une domination de Java depuis l'après bulle informatique.

Cependant, pour nuancer encore la réalité, je n'ai pas connu dans ma propre expérience d'application qui n'utilise pas moins de 3 langages (avec le quasi inévitable SQL avec ses variantes PL/SQL & co. !!!). Ensuite il est vrai qu'on peut parler de la dominante qui est impliquée dans les traitements les plus importants.

Il est toujours judicieux de se poser la question des outils les plus adaptés à utiliser et à adopter ceux qui le sont même si au départ nous ne les maîtrisons pas, à plus forte raison pour des projets qui portent sur des applications durables. C'est ce que j'ai fait récemment en allant à contre courant d'un avis quasiment imposé sur le langage Bash pour une application de supervision. J'ai dû forcer la main pour proposer de travailler avec Python et l'idée au départ n'a pas été bien acceptée car "il y avait déjà plusieurs modules qui tournaient en Bash" et que c'était une perte de temps d'utiliser un nouveau langage !

J'ai malheureusement expérimenté la perte de temps sur les débugage de scripts Shell et sur le risque de perdre du temps en maintenance du fait de l'absence de paradigme objet de . La nature de mon projet était de plus grande ampleur que celle des modules écrits en Bash. Les codes Shell sont difficilement maintenables, capricieux, et des grosses surprises peuvent vous attendre si vous migrez sur une autre version d'Unix par exemple (c'est du vécu) !!! Donc, la parole de fin, c'est de dire qu'à chaque chose sa place, mais qu'il faut éviter le mauvais casting !

[Jacti]

Je suis maintenant retraité mais j'ai terminé ma carrière comme "Expert en systèmes complexes à logiciel prépondérant", ce qui caractérise l'ingénierie système et pas seulement l'ingénierie logicielle. C'est principalement le domaine du spatial (satellites, missiles, navettes spatiales, etc), du nucléaires, du transport d'énergie (genre RTE), de l'avionique, des systèmes d'armes et, maintenant, les véhicules autonomes, etc. Dans l'armée de terre, les systèmes de commandement sont principalement écrits en Java et C++ (logiciels de plusieurs millions de lignes). Pour ma part ces 10 dernières années, dans ces domaines, j'ai vu surtout du Java, du C++ et il reste aussi du C. Dans ce genre de système il est TOTALEMENT exclu d'utiliser des langages à typage dynamique comme Python ce qui est une aberration pour ce genre de logiciels. Pour les fusées, il y aussi de l'ADA.
Ma conclusion c'est que pour choisir dans quels langages vous souhaitez travailler, il faut regarder les domaines d'application. Ceux qui veulent faire du Python ou du PHP doivent plutôt choisir les applications Web et encore, ça dépend lesquelles parce que dans les applis de e-commerce qui utilisent des web services transactionnels, il y a intérêt à regarder de près les environnements et les frameworks utilisés par l'entreprise avant de se lancer. Pour le big data, il faut connaître R (et Java pour les grosses applis). En gestion, je ne sais pas mais il y a encore du ... COBOL ! Pour "l'urbanisation" des systèmes d'information il est utile de connaître xml et xml. Il est également très utile de se pencher sur l'ingénierie dirigée par les modèles (IDM) (MDE et MDA).
L'avenir du développement c'est la production de code à partir de spécifications formelles comme ce qui a été fait, dès 1998, par exemple, pour les aspects sécurité de la ligne 14 du métro parisien, à savoir, spécifications formelles en B (langage de Jean-Raymond Abrial) et génération automatique du code en ADA. On est loin des langages Python, PHP, Perl et VBA ou VB.net.
Pourquoi l'avenir c'est la génération automatique du code à partir de spécifications formelles ? Parce que les systèmes deviennent de plus en plus complexes et que le code à écrire va devenir très rapidement non appréhendable par un humain. C'est déjà le cas pour certains logiciels d'intelligence artificielle ou les règles engendrées sont issues d'algorithmes d'apprentissages à partir d'énormes quantités de données (big data).

[TJ1985]

Les deux études sont intéressantes. Je rêverais de les voir croisées, afin d'obtenir une image de l'influence de la popularité d'un langage sur le niveau de salaire qu'il permet d'atteindre.
Sur le fond je m'interroge sur le langage comme critère d'engagement, et sur le niveau de maîtrise demandé. Lorsqu'on est à l'aise avec dans un paradigme il me semble assez aisé de maîtriser les langages qui l'appliquent.
Par contre l'omniprésence des frameworks et librairies complique le débat, car je pense qu'elles peuvent primer sur le choix du langage proprement dit.

[Grogro]

Pourquoi l'avenir c'est la génération automatique du code à partir de spécifications formelles ? Parce que les systèmes deviennent de plus en plus complexes et que le code à écrire va devenir très rapidement non appréhendable par un humain. C'est déjà le cas pour certains logiciels d'intelligence artificielle ou les règles engendrées sont issues d'algorithmes d'apprentissages à partir d'énormes quantités de données (big data).

Pour des systèmes qu'il est possible de spécifier formellement, oui. Pour des besoins spécifiques de pointe, oui. Dans la vraie vie de nos clients, donc le plus souvent de l'informatique de gestion pour les grands groupes, non. Parce que des spécifications cohérentes, non ambiguës, non contradictoires, exhaustives, j'en ai jamais vues. C'est pas pour rien si 70% des bugs qui remontent de la production sont des problèmes de conception.

[Jacti]

Pour des systèmes qu'il est possible de spécifier formellement, oui. Pour des besoins spécifiques de pointe, oui. Dans la vraie vie de nos clients, donc le plus souvent de l'informatique de gestion pour les grands groupes, non. Parce que des spécifications cohérentes, non ambiguës, non contradictoires, exhaustives, j'en ai jamais vues. C'est pas pour rien si 70% des bugs qui remontent de la production sont des problèmes de conception.

Je suis d'accord avec vous pour l'informatique de gestion. Dans mon premier job dans les années 70 je m'occupais des applications du personnel dans une grande banque. Même dans la convention collective des banques il y avait des contradictions. La directive de la direction du personnel, à l'époque, était de programmer ce qui était à l'avantage du salarié lorsqu'il y avait contradiction ou plusieurs possibilités.

[el_slapper]

Pour des systèmes qu'il est possible de spécifier formellement, oui. Pour des besoins spécifiques de pointe, oui. Dans la vraie vie de nos clients, donc le plus souvent de l'informatique de gestion pour les grands groupes, non. Parce que des spécifications cohérentes, non ambiguës, non contradictoires, exhaustives, j'en ai jamais vues. C'est pas pour rien si 70% des bugs qui remontent de la production sont des problèmes de conception.

Et puis désolé d'être pédant, mais si on fait une specs totalement complète, qui contient toutes les décisions du code, complète formellement, ce n'est plus une spec, c'est déjà du code. De plus haut niveau, mais c'est du code. A partir du moment ou la machine n'a plus qu'à suivre les ordres, alors les ordres, on appelle ça du code.

[Grogro]

Et puis désolé d'être pédant, mais si on fait une specs totalement complète, qui contient toutes les décisions du code, complète formellement, ce n'est plus une spec, c'est déjà du code. De plus haut niveau, mais c'est du code. A partir du moment ou la machine n'a plus qu'à suivre les ordres, alors les ordres, on appelle ça du code.

Ce qui me fait penser à ce strip de l'excellent CommitStrip :

[Jacti]

Et puis désolé d'être pédant, mais si on fait une specs totalement complète, qui contient toutes les décisions du code, complète formellement, ce n'est plus une spec, c'est déjà du code. De plus haut niveau, mais c'est du code. A partir du moment ou la machine n'a plus qu'à suivre les ordres, alors les ordres, on appelle ça du code.

Les spécifications décrivent le QUOI, le code décrit le COMMENT.
Les spécifications ne sont pas des ordres donnés à la machine mais des assertions.Avez-vous déjà utilisé des systèmes comme LCF, la méthode B de Jean-Raymond Abrial ou COQ et fait des preuves avec ?
Connaissez-vous le lambda-calcul typé d'ordre supérieur, la théorie des types, la sémantique axiomatique, la logique de Hoare, etc. ?
Avez-vous fait généré du code à partir de spécifications formelles ?

[alama32]

Par contre je rêverais d'être un dev assembleur, le truc rare, voire trop rare.

Normal c'est du code presque machine, après, y a plus que le binaire.. lol Mais il est très simple, ce n'est jamais que jouer avec les registres du CPU ou GPU (comme AGAL), on peut faire des .exe et des .com il est souvent utilisé pour faire des drivers bien spécifique. Il n'est pas objet, il est séquentiel. Il est nécessaire d'avoir le set d'instruction de la puce à programmer, comme X86, cherche le logiciel MASM un vieux portable avec un DOS 6 sera largement suffisant. il y aura DEBUG qui est très utile. le point d'entrée des exe est l'adresse 100 si je me rappelle bien. Il existe des IDE qui te permettent de lire un code en hexadécimal, ce qui est une représentation comprimée des bytes.

Cherche sur le web. voici déjà un lien qui pourrait t’intéresser:
http://www.masm32.com/

[Kannagi]

Normal c'est du code presque machine, après, y a plus que le binaire.. lol Mais il est très simple, ce n'est jamais que jouer avec les registres du CPU ou GPU (comme AGAL), on peut faire des .exe et des .com il est souvent utilisé pour faire des drivers bien spécifique. Il n'est pas objet, il est séquentiel. Il est nécessaire d'avoir le set d'instruction de la puce à programmer, comme X86, cherche le logiciel MASM un vieux portable avec un DOS 6 sera largement suffisant. il y aura DEBUG qui est très utile. le point d'entrée des exe est l'adresse 100 si je me rappelle bien. Il existe des IDE qui te permettent de lire un code en hexadécimal, ce qui est une représentation comprimée des bytes.

Cherche sur le web. voici déjà un lien qui pourrait t’intéresser:
http://www.masm32.com/

Je trouve cela complètement inutile de faire de l'asm avec un OS , c'est quoi le but/intérêt de faire de l'asm en faisant appel a L'OS ou a d'autre lib C ?
Je ne vois pas forcément l’intérêt de faire des driver en asm , en terme d'optimisation un compilateur C fera mieux sur des plateforme comme le X86 ou l'ARM.

Bref pour ma part je le déconseille vivement du masm32 ou même du x86 (sauf si faire une appli avec une syntaxe assembleur vous plaît) , je conseillerai largement un micro contrôleur ou une vielle machine

Par contre je rêverais d'être un dev assembleur, le truc rare, voire trop rare.

J'ai envie de dire pourquoi ça serait un rêve ? pour impressionner les filles ? être un gourou du code ?
J'ai codais sur de l'assembleur sur plusieurs machine différente (grosso modo de la Nes a la PS2).
Mais le truc le plus important c'est l'algorithmique et la rigueur , si tu code en asm comme les pieds l’intérêt est proche de zéro.

[sarnikoff]

J'aimerais savoir dans quel langage est "écrit" développez. com.

Ici, je suis sur un magnifique éditeur, qui ressemble à un outil proposé en php .
Simplement :
Existe-t-il le même outil dans tous les langages cités ?

De plus compte tenu de la gestion de l' information,
dans quelle rubrique figure la comparaison des SGBD ou autre gestion de données ?

[el_slapper]

Les spécifications décrivent le QUOI, le code décrit le COMMENT.
Les spécifications ne sont pas des ordres donnés à la machine mais des assertions.Avez-vous déjà utilisé des systèmes comme LCF, la méthode B de Jean-Raymond Abrial ou COQ et fait des preuves avec ?
Connaissez-vous le lambda-calcul typé d'ordre supérieur, la théorie des types, la sémantique axiomatique, la logique de Hoare, etc. ?
Avez-vous fait généré du code à partir de spécifications formelles ?

Grogro a déjà répondu avec son grand classique(que j'ai eu la flemme de googler). D'ailleurs, le SQL est du code, mais ça ne décrit jamais que le quoi, pas le comment, c'est un langage descriptif. Une spec formelle assez balaise pour se compiler(donc pour être transformée dans un code plus proche du langage machine) est elle-même du code. Descriptif, évidemment, pas prescriptif, mais le SQL n'est pas autre chose.

Et je n'ai d'ailleurs pas dit que c'était facile, ou que c'était une mauvaise idée. C'est juste une autre manière de coder. On code le quoi, pas le comment.

[Jacti]

Grogro a déjà répondu avec son grand classique(que j'ai eu la flemme de googler). D'ailleurs, le SQL est du code, mais ça ne décrit jamais que le quoi, pas le comment, c'est un langage descriptif. Une spec formelle assez balaise pour se compiler(donc pour être transformée dans un code plus proche du langage machine) est elle-même du code. Descriptif, évidemment, pas prescriptif, mais le SQL n'est pas autre chose.

Et je n'ai d'ailleurs pas dit que c'était facile, ou que c'était une mauvaise idée. C'est juste une autre manière de coder. On code le quoi, pas le comment.

Je vous parle de spécifications formelles permettant de faire des preuves vous me répondez SQL qui n'est même pas un langage "Turing-complet" : il ne permet pas de coder toutes les fonctions calculables (thèse de Church-Turing) comme, par exemple, le balayage d'arborescences. Vous savez faire des preuves, vous, avec SQL ? et vous oubliez que les résultats se trouvent déjà dans la base de données et que SQL ne fait qu'extraire les n-uplets qui répondent à la question. Ça n'a donc absolument rien à voir avec ce dont je parle dans mes messages.
Par ailleurs je ne sais pas ce qu'est un langage descriptif, ça ne fait pas parti du vocabulaire sur les langages informatiques. Vous voulez dire plutôt "déclaratif" mais ça n'en est pas un. Un langage déclaratif c'est un langage comme Prolog.
Ceci étant vous n'avez répondu à aucune de mes questions.
Allez faire un tour par ici : http://www.college-de-france.fr/site...-2014-2015.htm pour comprendre ce que sont des spécifications et des méthodes formelles.

[el_slapper]

(.../...)

On ne parle pas de la même chose. Donc reprenons. Vous avez tout un tas d'outils très rigolos pour garantir avec certitude l'exactitude de vos specs. C'est sans doute bien utile dans certains domaines. Dans le mien, c'est surtout bien trop couteux(alors même qu'on jour avec la vie des gens - mais bon, le ministère préfère baisser les dotation informatiques des hôpitaux, tout en accroissant la pression réglementaire sur les éditeurs de logiciels, donc on fait avec ce qu'on a).

Mais moi j'insiste : si la spec est compréhensible par la machine, alors c'est déjà du code. C'est la définition. Quand je dis que c'est descriptif, ça veut dire que ça décrit le résultat attendu, tout simplement. Que SQL ne soit pas Turing complet, je n'en ai rien à foutre. Je lui dis ce que je veux "SELECT BIERE FROM FRIGO", et il se démerde pour aller chercher la bière au frigo(je sais, il est pourri, mon exemple, mais il est rigolo). Je n'ai pas codé le comment. J'ai codé le quoi(alors que dans un langage standard, effectivenent je vais coder le comment). Il y a des trous? C'est bien possible. Après tout, c'est un langage spécialisé sur quelques tâches bien précises de manipulations de données. Non, en effet, ça ne passe pas l'aspirateur. Ca n'est pas mon propos. Je ne cherche pas l'outil magique qui sait tout faire.

Tout ces trucs sur des specs magiques qui passent elles-même l'aspirateur, c'est exactement pareil. Encore une fois, je ne critique pas, j'imagine que dans des domaines où on a les moyens de s'atteler à la qualité totale, c'est certainement une sécurité qui n'est pas un luxe. Maintenant, croire qu'il suffit d'aligner des formules mathématiques pour régler un problème, ça sous-entend que le problème est bien défini au départ. Ce qui est à peu près le cas quand le problème, c'est de lancer une fusée en orbite, ou déterminer l'enveloppe d'altitude optimale de vol pour un avion de ligne, voire même de doser la quantité de radiations émises par les outils de télédiagnostic médical. Quand le problème, c'est de mettre en place une gestion informatisée de la prescription que les médecins hospitaliers en balancent pas par la fenêtre au bout de 45 secondes, c'est très différent. Le but du jeu n'est pas seulement d'avoir zéro bug. Ca, à la rigueur, c'est facile(sauf pour les intraveineuses, mais je digresse). Le but du jeu est d'avoir une interface qui rassure des vieux tyrans de 70 ans, qui n'ont aucune patience pour "ces conneries"(ce mot désignant l'ensemble de nos professions liées à l'informatique), et qui considèrent tout changement comme une atteinte inacceptable à leur pouvoir de droit divin sur tout ce qui se passe dans l'hôpital.

Dit autrement, on est sur de l'humain. Bons, certains sont certes beaucoup plus civilisés que la description que je viens de faire, mais "des gens vont mourir" à chaque proposition, et à chaque contraire, c'est une réaction fréquente, dans notre cas. Le but du jeu est donc de coder une interface ou l'utilisateur ne se rend même pas compte qu'il utilise un logiciel. Dès qu'il s'en rend compte, on a perdu. Et ça, ce n'est pas une spec formelle qui va nous le faire. C'est de la diplomatie, de l'ergonomie, du doigté, et du graphisme. Et de la performance, aussi - dès que ça rame, ça commence à ressembler à un logiciel. Et puis franchement, faire une spec formelle pour garantir que volume = débit * durée, euh, c'est un peu la bombe atomique pour écraser une mouche.

Donc je reprends mon analyse, en précisant le domaine : je ne suis pas sur des algorithmes scientifiques de pointe. Je ne suis pas dans un domaine ou la certitude de l'exactitude de l'algorithme et de son implémentation sont l'alpha et l'oméga du développement informatique. Je suis sur des domaines complexes, ou la difficulté n'est pas l'algorithme, mais l'immense quantité de choses à gérer, ainsi que la réaction de l'utilisateur face à celles-ci. Et de ce que je lis sur ces forums, c'est la majorité de l'informatique aujourd'hui. Les gens qui gèrent des flux bancaires, leur algo, il est facile : on additionne, et les grands jours, on soustrait. Mais sur un nombre invraisemblable d'opérations, avec des exigences réglementaires fortes(notamment en termes de traçabilité pour audit), et une exigence de tenue à la charge délirante. Ces gens-là n'ont pas une vie facile, et des méthodes formelles ne leurs seraient d'aucune aide.

Pour en revenir au début, j'ai lu le mot assertion. On peut faire une assertion "passif après = passif avant plus investissement"(ou moins, la compta n'a jamais été mon fort). Imaginons qu'on le fasse de manière formelle, et que le système soit capable d'en tirer les opérations nécessaires pour appliquer l'algorithme. ça veut dire que la spec formelle est interprétable telle quelle par le système informatique, et est suffisante pour être exécutée. C'est donc, à ce niveau, étymologiquement parlant, du code. Très différent du COBOL qui fait ça en vrai, mais c'est du code aussi.

[Jacti]

...
Mais moi j'insiste : si la spec est compréhensible par la machine, alors c'est déjà du code. C'est la définition. Quand je dis que c'est descriptif, ça veut dire que ça décrit le résultat attendu, tout simplement. Que SQL ne soit pas Turing complet, je n'en ai rien à foutre. Je lui dis ce que je veux "SELECT BIERE FROM FRIGO", et il se démerde pour aller chercher la bière au frigo
...

Dans ton exemple, BIERE et FRIGO sont des entités bien définies dans la base de données. La plus grande partie du travail a été faite dans le MCD si on utilise Merise. Le SELECT ne fait que la jointure entre les tables en extrayant les n-uplets qui répondent à la question. Ce n'est donc pas le quoi que tu exprimes en SQL mais du code, effectivement et le SELECT n'est qu'un appel à un algorithme pré-câblé dans le SGBD. C'est donc très différent d'une spec formelle, ça n'a strictement rien à voir. Des assertions (par exemple en logique de Hoare) produisent non pas du code mais des règles qui servent ensuite à prouver (au sens mathématique du terme) la spec formelle qu'on a écrite. Ce que tu dis montre, et je m'en excuse, que tu ne comprends pas ce qu'est réellement une spec formelle. Ce n'est en rien du code exécutable. Elle sert à faire des preuves qui permettent de s'assurer que le code généré automatiquement est sûr comme pour le logiciel du métro Meteor ou d'un compilateur d'un gros sous-ensemble du langage C certifié comme CompCert.
Pour ce qui est de ton environnement, je sais que le milieu médical est assez spécial et je connais les réticences (c'est un euphémisme) de ce milieu pour ce qui est de l'informatique. C'est en train de changer un peu avec l'arrivée des robots chirurgicaux. Pour l'instant, il est clair que ce que je raconte n'est pas applicable à tous les milieux mais c'est quand même la tendance générale future à moyen/long terme.
Je te souhaite bon courage...

[Grogro]

On ne parle pas de la même chose. Donc reprenons. Vous avez tout un tas d'outils très rigolos pour garantir avec certitude l'exactitude de vos specs. C'est sans doute bien utile dans certains domaines. Dans le mien, c'est surtout bien trop couteux(alors même qu'on jour avec la vie des gens - mais bon, le ministère préfère baisser les dotation informatiques des hôpitaux, tout en accroissant la pression réglementaire sur les éditeurs de logiciels, donc on fait avec ce qu'on a).

Voilà tout est dit. Du coup Jacti ça m'intéresse beaucoup des "méthodes formelles", mais outre l'automatisation de ligne de métro (et ça c'est déjà un projet de ouphe gueudin vraiment impressionnant), peux-tu nous dire dans quels contextes ça marche ?

Et puis il y a un point dans la réponse d'el slapper qui est fondamental : le plus dur à gérer dans l'informatique, c'est l'humain. Qu'il soit donneur d'ordre (MOE) ou utilisateur du produit. Ca n'est pas quelque chose que tu peux spécifier formellement. Ce n'est même pas spécifiable tout court.

[Jacti]

Voilà tout est dit. Du coup Jacti ça m'intéresse beaucoup des "méthodes formelles", mais outre l'automatisation de ligne de métro (et ça c'est déjà un projet de ouphe gueudin vraiment impressionnant), peux-tu nous dire dans quels contextes ça marche ?

Et puis il y a un point dans la réponse d'el slapper qui est fondamental : le plus dur à gérer dans l'informatique, c'est l'humain. Qu'il soit donneur d'ordre (MOE) ou utilisateur du produit. Ca n'est pas quelque chose que tu peux spécifier formellement. Ce n'est même pas spécifiable tout court.

Les méthodes formelles ça fonctionne surtout lorsqu'il y a des spécifications précises ou des normes comme dans l'aéronautique (il y a certaines parties de logiciel qui doivent être prouvées formellement pour obtenir la certification). Il y a aussi des choses comme les cartes à puces intelligente, par exemple : http://www.electronique-eci.com/news...al7-du-secteur. La certification EAL7 garantit la vérification de façon formelle de la conception du modèle, le test du modèle et la résistance de celui-ci pour un environnement extrêmement protégé.La méthode B, déjà utilisée pour le métro Meteor, a été utilisée plusieurs fois dans le domaine ferroviaire. Il y a aussi utilisation de méthodes formelles pour des micro noyaux d'OS comme ici : https://www.lembarque.com/le-logicie...kerlink_005927. Curieusement c'est plus utilisé pour l'embarqué que pour logiciel classique. Certainement parce que, dans le domaine de l'embarqué, il y a plus de normes et de besoins de certification. Il y a également des applications dans la robotique modulaire. A terme, tout ce qui sera système autonome (robot, automobile, sondes spatiales pour lesquelles c'est déjà le cas, protocoles cryptographiques, téléphonie mobile intelligente, etc) devra faire l'objet de vérifications formelles au moins pour les aspects sécurité. Je te fais une remarque : un donneur d'ordre c'est la maîtrise d'ouvrage (MOA), c'est celui qui réalise qui est la maîtrise d'œuvre (MOE). En informatique de gestion, je n'ai pas d'exemple mais, dans ce domaine, l'humain compte plus que la technique comme tu le soulignes.