Discussion :

[el_slapper]

C'est essentiellement la différence entre un travail utilisable fait rapidement et un travail de très faible valeur ajoutée qui demande un temps fou.

[maske]

Même si pour être honnête la contribution apportée par une thèse en informatique est souvent très très très modeste (voir mineure (voir insignifiante))

[Shepard]

Tu enfonces bien sûr des portes ouvertes, tout le monde (au moins sur ce forum) sait très bien que les informaticiens sont utiles et les mathématiciens inutiles

Plus sérieusement, la finalité est totalement différente. Les mathématiciens qui travaillent dans la recherche assistée de preuves par exemple (avec un magnifique exemple : Coq, que j'utilise en tant qu'informaticien mais que je ne comprends pas) ont travaillé pendant des décennies sur un projet qui ne porte ses fruits que depuis quelques années. Mais a présent les informaticiens disposent d'un outil qui leur permet de créer des programmes certifiés. Pour celui qui gère le pilotage d'un avion, le fonctionnement d'une centrale nucléaire, le lancement d'une fusée ou des simulations physiques, je trouve que c'est un argument non négligeable pour justifier la qualité de son programme. (Il me semble que le compilateur GCC a également été validé par un tel outil).

Oui nous sommes pratiques. Mais si des collègues mathématiciens qui me connaissent passent, ils ne pourront pas me reprocher d'avoir laissé courir des rumeurs à leur sujet

[Matthieu Vergne]

Luckyluke34 a posté avant moi, mais ça m'empêchera pas de faire mon speech. {^_^}

Autant le titre de la news, je le trouve inapproprié et c'est pour ça que je comptais répondre, autant le contenu de la news, qui ne semble que reprendre les termes d'un autre, ne me donnent pas du tout le ressenti du titre et est beaucoup plus neutre et en accord avec mon expérience : l'ingénierie n'est pas de la technique, un ingénieur n'est pas un technicien. Le technicien programme les blocs, l'ingénieur assemble les blocs selon une certaine méthode, le chercheur design les méthodes. Ce sont trois jobs complémentaires, certains ayant des capacités dans plus d'un job. Gerry Sussman semble se concentrer sur les deux premiers, et exprime visiblement que, désormais, on a atteint un niveau où il n'est plus nécessaire d'avoir des compétences de technicien pour avoir un niveau raisonnable d'ingénierie (Golgotha, je pense que ce que tu critiques est précisément ce biais introduit par la news, et non dans les termes de l'auteur original). Les besoins se sont bien séparé, et de mon point de vue ça permet d'avoir des métiers clairs qui ne se marchent pas dessus. Un ingénieur n'est pas nécessairement un expert programmeur, et n'a pas besoin de l'être. Et ça c'est un avantage.

Or le titre tourne complètement à l'envers le message : un ingénieur n'est pas un "vrai" programmeur, il se "contente" d'assembler. Style un ingénieur est un parasite qui ne dit pas son nom, et qu'un "vrai" programmeur est mieux qu'un ingénieur. La question finale reprend d'ailleurs bien ce biais (qu'on retrouve néanmoins dans l'article d'origine) : non la programmation ne se résume pas à l'assemblage de bibliothèques, mais c'est la composante première d'un job d'ingénierie. Si le programmeur doit maîtriser son langage pour savoir faire un ensemble de tâches simples, l'ingénieur doit maîtriser un ensemble d'outils différents pour effectuer des tâches complexes. L'un n'empêche pas l'autre, mais ne le nécessite pas non plus. Et cette dichotomie est appréciable car on favorise la coopération (par la complémentarité) plutôt que la compétition.

Quand FoinFoin parle de la tristesse de ne faire qu'assembler du code ensemble, c'est une logique de programmeur, pas d'ingénieur : le fait de ne pas maîtriser l'ensemble du code n'est pas un problème en soit. Ça rassure certains mais ça n'a rien de nécessaire. Est-ce qu'on a besoin de maîtriser sur le bout des doigts la chimie pour faire un bon cuisinier ? Si au final, ce qu'on fait ne marche pas, soit on creuse pour augmenter sa maîtrise de l'ingrédient, soit on en utilise un autre plus adapté. Ici c'est pareil, soit on prend une logique de programmeur (on creuse le code pour le maîtriser et le faire évoluer) soit on prend une logique d'ingénieur (on enrichi son ensemble d'outils). Les deux solutions sont possibles, il n'y en a pas une de mieux que l'autre. Mais pour comprendre ça il faut bien comprendre les deux approches et les avantages/limitations de chacune. Notamment, le programmeur passe du temps à programmer, l'ingénieur à faire de la veille techno. Le programmeur maîtrise donc mieux ses pièces, mais l'ingénieur en connaît davantage. Le programmeur optimise mieux, l'ingénieur résout plus rapidement les nouveaux problèmes. On ne peut pas devenir super bon dans les deux à la fois, car comme Saverok le souligne, ça demande du temps, et du temps on n'en a pas à foison pour découvrir dans les moindres détails tous les outils existants (ou ne serait-ce que les plus utilisés).

Pour ma part je suis à la fois programmeur (je programme beaucoup from scratch), ingénieur (c'est ma formation initiale) et chercheur (c'est ma formation actuelle), et donc pour moi la différence est claire : il n'y a pas de hiérarchie, on peut être l'un sans être l'autre, mais comme tout si on en combine plusieurs c'est un avantage car on couvre plus large. Néanmoins, ma manière de faire est avant tout celle d'un programmeur : je préfère maîtriser mes quelques outils plutôt que d'avoir une grosse liste d'outils.

je ne sais pas si ce Gerry Susmann a raison mais justement la capacité d'être dans l'abstraction c'est ce qui manque atrocement dans les projets informatiques notamment ceux sur lesquels j'ai pu travailler.
C'est toujours ce que j'ai voulu expliquer sur ce forum ,programmer c'est bien mais il faut construire toute l'étape en amont d'un projet qui consiste à conceptualiser sur le dit projet et à dégager les couches métiers dans une couche abstraite.

Ce dont tu parles est de la modélisation conceptuelle, et non de l'abstraction au sens du billet d'origine, à savoir l'abstraction telle que conçue dans les langages de programmation pour les langages de programmation. Ce n'est pas parce que tu maîtrises l'abstraction en Java par exemple que tu est capable de designer un projet avec les concepts adaptés (j'ai pu le constater sur certains projets, où l'abstraction est utilisée correctement mais avec une conceptualisation très sommaire). L'abstraction dont on parle ici est un moyen technique, et non la compétence générale dont tu parles.

[TheLastShot]

C'est essentiellement la différence entre un travail utilisable fait rapidement et un travail de très faible valeur ajoutée qui demande un temps fou.

Ce qui est "marrant" c'est que pendant un de mes stages dans une grande entreprise international spécialisé dans le développement de logiciel de simulation, 3D, etc. dont je tairais le nom j'ai entendu le même discours. C'est toujours la même chose, faire les choses le plus vite possible, parce que sinon on perd de l'argent...
Ce qui est moins drôle c'est qu'aujourd'hui c'est un peu l'hécatombe pour eux... Forcément, avec des concepts tels que "les erreurs documentées" (en gros, plutôt que de résoudre les problèmes, on dit "ouais on connait, on sait plus ou moins, ce qui la provoque") on ce retrouve avec tout un logiciel (voire une gamme de logiciel) qui risque de planter à tout moment étant donné que le code en question se trouve au fin fond des entrailles des codes sources.
En revanche, dans les quelques boites que je connais où les mecs n'ont pas peur de se sortir les doigts de leur fondement respectif afin de les utiliser sur leur clavier (toujours respectif, faut un minimum d'hygiène), il y a "étrangement" beaucoup moins de problèmes.

Soit dit en passant, ce n'est peut-être qu'un extrapolation de ma part, mais pour quelqu'un qui semble défendre l'utilisation de bibliothèques, je trouve cela un peu irrespectueux envers ceux qui développent ces bibliothèques de parler de "travail de très faible valeur ajoutée".

Et enfin, parce que cette immonde expression me hérisse toujours le poil :

mais il ne faut pas ré-inventer la roue en permanence

(Pour la défense de l'auteur du message, le "en permanence" ajoute une petite nuance qui justifie un peu plus ses propos... mais quand même...)
Il ne faut pas ré-inventer la roue. En voilà une, banalité (pour le coup c'est un peu le cas de toutes les expressions toute faites de ce genre), parmi les plus énervantes que je connaisse.
A tous ceux qui prennent cette expression un peu trop au pied de la lettre, je leur demanderais d'aller faire un petit tour sur l'historique de la roue en question !
En effet, il me semble qu'il y a une nette différence entre la roue telle qu'elle a été inventée (une roue pleine en pierre) et les roues que l'on retrouve aujourd'hui sur nos voitures (et heureusement, sinon je vous raconte pas l'état des routes...). En effet, la roue a subit bon nombre de modifications qui fait que, mis à part sa forme grossière, la roue d'aujourd'hui n'a pas grand chose à voir avec la roue d'origine... Cette dernière a donc bien été réinventée, et ce à maintes reprises. Ce qui n'a pas été réinventé en revanche, c'est le concept de la roue, mais la manière dont on "implémente" ce concept a bien changée.
Ensuite, cette expression donne l'impression que la roue symbolise l'invention ultime, le saint graal de la technologie et que jamais on ne pourra faire mieux... A cela je répond: essayez de grimper un escalier avec une chaise roulante (ceci est évidemment rhétorique, et si vous le faites réellement, je ne saurais être tenu responsable en cas de blessures). La roue est une réponse à un problème (permettre le déplacement d'un objet d'un point A à un point B) dans une contexte donnée (un sol dur, relativement plat, avec une pente pas trop élevée). Mais en dehors de ce contexte la roue n'est clairement pas la bonne solution (ce n'est pas pour rien que les bateaux n'ont pas de roues...).

Et bien en ce qui concerne l'informatique, c'est la même chose... Au lieu d'utiliser cette expression, remplacer le mot "roue" par n'importe quoi et vous verrez que ça parait déjà moins évident... Petit essaie : "Il ne sert à rien de réinventer l'ordinateur" => Si je vous dis ordinateur quantique, supercalculateur, smartphone, tablettes, etc. ça vous parle ? J'ai besoin d'être plus explicite ?

Alors par pitié, arrêter de sortir cette phrase à tord et à travers. Je comprends que tout le monde n'ai pas l'envie, ni même la capacité, de se lancer dans des projets aussi complexe, mais ce n'est pas une raison pour décrédibiliser de la sorte ceux qui ont le courage de le faire et qui nous permettent aujourd'hui d'avoir les bibliothèques/frameworks que l'on a, et qui nous permettront demain d'en avoir de meilleurs.

[RyzenOC]

la roue d'aujourd'hui n'a pas grand chose à voir avec la roue d'origine... Cette dernière a donc bien été réinventée, et ce à maintes reprises.

Non, elle n'a pas été réinventée, elle à été améliorer.

2 conditions doivent être réunie pour "ré-inventer" la roue:
1) Si tu peut te permettre financièrement (le temps c'est de l'argent) et intellectuellement de refaire une bibliothèque qui fait grosso-modo la même chose, mais en offrant plus de fonctionnalité ou en étant plus performante
2) Si tu as le temps et l'argent de maintenir ce code, car une bibliothèque elle ne doit pas être jetable, sinon il n'y aucun intérêt.

Si tu remplie ces 2 condition, alors oui tu peut crée ton truc dans ton coin.
Dans la réalité, aucune boite ne s'amuse a re-crée un QT, ou un numpy, sa n'aurais aucun sens.

Les bibliothèques permettent de faire 50% du boulot gratos et de rendre la maintenance d'un code plus facile, car utiliser une bibliothèque c'est délégué la maintenance de cette dernière à d'autre développeurs (spécialisé en plus).

Apres c'est comme tous, faut pas non plus rentrer dans les excès. On utilise pas une bibliothèque ou un framework pour faire un print ou une addition.

[maske]

mais en offrant plus de fonctionnalité ou en étant plus performante

Oui ou autre chose. La performance n'est pas le seul critère d'évaluation d'un outil. Selon le critère, on peut avoir des raisons de (re)faire une nouvelle bibliothèque.

Je sais pas si ça vaut la peine d'argumenter sur un proverbe, qui ne veut pas dire ce qu'il veut dire littéralement. J'ai toujours pensé que le sens en était immédiat (me trompe peut-être).

[herdans]

On aurait pû élargir le débat sur l'utilisation importante des bibliothèques et l'éventuelle nécessité de suivre les MAJ de ces dites bibliothèques. Mais du coup, c'est un peu moins vendeur comme sujet.

[TheLastShot]

Non, elle n'a pas été réinventée, elle à été améliorer.

Dans ce cas donne moi ta définition de "réinventer". Car à partir du moment où les matériaux ont changé, que la structure a changée, que la méthode de fabrication a changée, BREF que tout a changé mis à part le nom... Je ne vois pas en quoi il s'agit juste d'une amélioration (ce serait comme dire que la machine de Turing n'est qu'une amélioration des machines à calculer d'avant, et pourtant on parle bien d'invention).

Si tu remplie ces 2 condition, alors oui tu peut crée ton truc dans ton coin.
Dans la réalité, aucune boite ne s'amuse a re-crée un QT, ou un numpy, sa n'aurais aucun sens.

Pourtant il me semble que tu viens toi-même de citer deux projets qui sont des "ré-inventions" (car oui, Qt et numpy, jusqu'à preuve du contraire, ne sont pas les seuls sur leurs marchés respectifs).
Et si tu veux un exemple peut-être un peu plus parlant de boites qui font la même chose : Unreal Engine, Unity, CryEngine (sans parler des boites qui développement leur moteur pour eux et le garde)... Ça, c'est fait !

Les bibliothèques permettent de faire 50% du boulot gratos et de rendre la maintenance d'un code plus facile, car utiliser une bibliothèque c'est délégué la maintenance de cette dernière à d'autre développeurs (spécialisé en plus).

Prenons un petit exemple: Wordpress. Le jour où Wordpress sort sa version 5 avec une super feature que ton client veut absolument mais que parmi les 50 plugins que t'as installé t'en a 20 qui ne seront pas compatible, en plus des 15 autres qui étaient déjà buggés, que les développeurs te répondront d'attendre bien gentiment qu'ils aient la foi (parce qu'honnêtement, pour bosser sur wordpress c'est un élément indispensable) de les rendre compatibles et que toi, pendant ce temps là, tu vas galérer parce que tu n'es pas capable de faire le moindre fix même à l'arrache... Tu vas pleurer ! (Et de mon côté je continuerais d'avancer, parce que je connais absolument toutes les technologies que j'utilise... Et ainsi la tortue aura dépassé le lièvre)
(Après, je parle à la deuxième personne du singulier, mais ce n'est absolument pas une attaque envers toi. Ne le prends pas personnellement, c'est juste une manière de parler)

Apres c'est comme tous, faut pas non plus rentrer dans les excès. On utilise pas une bibliothèque ou un framework pour faire un print ou une addition.

Sans aller jusqu'au print, il y a malheureusement beaucoup de cas où un "dev" va aller direct chercher dans la liste des plugins pour la moindre petite fonctionnalité (alors que bien souvent, ça ne prendrait même pas une heure à implémentée, ce serait cohérent avec le reste du projet, il n'y aurait aucun problème...)

[RyzenOC]

Et si tu veux un exemple peut-être un peu plus parlant de boites qui font la même chose : Unreal Engine, Unity, CryEngine (sans parler des boites qui développement leur moteur pour eux et le garde)... Ça, c'est fait !

Peut être parce que c'est justement le cœur de métier de ces boites justement...
Je trouve normal qu'un gros éditeur de jeu crée son propre moteur, c'est rentable à long terme et sa donne plus de liberté commercial.

Maintenant si tu veut crée ton moteur de jeu pour ton jeu libre a toi... on en reparle dans 10ans.

Prenons un petit exemple: Wordpress. Le jour où Wordpress sort sa version 5 avec une super feature que ton client veut absolument mais que parmi les 50 plugins que t'as installé t'en a 20 qui ne seront pas compatible, en plus des 15 autres qui étaient déjà buggés, que les développeurs te répondront d'attendre bien gentiment qu'ils aient la foi (parce qu'honnêtement, pour bosser sur wordpress c'est un élément indispensable) de les rendre compatibles et que toi, pendant ce temps là, tu vas galérer parce que tu n'es pas capable de faire le moindre fix même à l'arrache... Tu vas pleurer !

Ok alors crée ton propre CMS, mais quand tu aura ton truc de 10000 lignes de code avec des failles toutes les 10 lignes faudra pas pleurer...

Maintenant si tu est le PDG d'une grosse boite, ou ton CMS, moteur de jeu ou je ne sais quoi tu pourra l'utiliser dans tous tes futur projet, alors oui fonce, mais je doute que se soit le cas.

[lebaba]

Pensez-vous que la programmation de nos jours se résume à l'intégration de bibliothèques ?

Je pense que la réponse à la question dépend du domaine dans lequel on évolue.
Pour ma part, je travaille principalement sur des applications de gestion de SI en environnement JEE. J'ai remarqué, au bout de quelques années, que mon travail se résumait justement à assembler des framework pour les faire fonctionner ensemble. Il m'arrive de temps à autre, en implémentant quelques algos, d'écrire mon propre code. Mais même là, je m'appuie énormément sur les librairies. Par exemple pour trier une collection, je ne vois pas pourquoi dois je réécrire le code alors qu'il existe la lib CollectionUtils d'apache et qu'elle fait bien ça. Aussi, n'a t'on pas besoin toujours de lire le code. La provenance de la lib est un indicateur de confiance. Quand ça vient d'apache ou de spring c'est pas comme si ça a été fait par M. X
On peut aller plus loin dans cette logique, demain le métier de développeur dans les SI se résumerait à aller faire ses courses en achetant (ou pas) les composants dont on a besoin et venir les assembler.
Cependant, je pense qu'on a toujours besoin d'avoir de solides bases en programmation pour justement écrire des lib spécifiques car on en aura toujours besoin.

[NSKis]

Si les ingénieurs modernes ne sont plus de "vrais programmeurs", ce n'est pas de leur fautes et surtout il y a une raison indépendante de leur volonté!

Mais pourquoi donc ces "faux programmeurs" se limitent à empiler des bibliothèques réalisées par d'autres??? Une seule raison: le fric!!!

Que l'on me montre un seul dirigeant financier d'accord de laisser ses ingénieurs faire du travail de "vrais programmeurs" alors que des bibiothèques déjà existantes peuvent être utilisées à moindre coût...

[doudouam]

Pendant ce temps, une roue est (toujours) une pièce mécanique de forme circulaire tournant (toujours) autour d'un axe passant (toujours) par son centre.

[Shepard]

J'ajouterai d'ailleurs que la roue est l'une des huit machines simples.

[el_slapper]

Bon, j'aurais du être plus explicite. Suivant les cas, un niveau plus ou moins élevé de maitrise est nécessaire. La macro excel que je viens de bricoler en une demi-heure pour dépanner une collègue n'a pas besoin de démonstration formelle. Un modèle de vol de fusée habitée beaucoup plus. Dans le deuxième cas, évidement, les méthodes formelles ont leur utilité. Dans le premier cas, aucune.

L'ingénieur, le vrai, sait quand il a besoin de la puissance formelle des mathématiques, et quand il peut se passer de leurs lourdeurs. Parfois, on spécifie jusqu'au niveau du pseudo-code(ça m'est arrivé, pour des algos sensibles stratégiques, mais vraiment pas souvent). Parfois, on ne spécifie pas du tout(la macro que je viens de faire, comme des centaines avant elle). Souvent, on est entre deux. Il faut adapter son effort de spécification formelle au contexte, au besoin, au délai, au budget, à la difficulté, à la criticité.

Donc, parfois, passer des années à démontrer que quand une lumière est allumée alors qu'elle était éteinte, c'est qu'on a appuyé sur l'interrupteur(lire à partir de "Take programming-intensive courses."). Pour aller dans l'ISS, c'est essentiel. Pour découper un tableau EXCEL en colonnes plus lisibles, c'est risible.

[habibdu70]

bonjour,

Personnellement, je pense que le développement a toujours été "l'assemblage de bibliothèques" mais à une échelle différentes.

Dans les années 80, les bibliothèques étaient : "addition", "soustraction", etc... (j’exagère un peu )

Maintenant les bibliothèques c'est "envoyer un email", "ouvrir une nouvelle", mais aussi "afficher la position de l'utilisateur" etc...

d'ailleurs 90% des développements moderne c'est le développement de bibliothèque (API, web services, dll etc....).

De manière générale (à part pour les développeurs assembleurs), on peut considérer que le développement a toujours été l'assemblage de bibliothèque. (encore plus vrai avec les langages plus ou moins objets).

Mais il est clair que re développer le comportement du pointeur de la souris sur l'ecran, ou l'ouverture d'une fenêtre à l’écran, n'a vraiment aucun intérêt.

Après ce qui rends le développement moins "gymnastique intellectuelle", c'est le fait qu'aujourd'hui le code est beaucoup plus modulaire et découpe par fonctionnalité.

Avant on pouvais avoir une méthode qui en fonction d'un input faisait plusieurs traitement/calcul, écrire sur des fichiers/DB pour ensuite afficher le resultat à l'utilisateur.

aujourd'hui cette méthode à tendance à être découpé en 4/5 modules, ce qui fait que chaque partie devient plus légère et ce concentre sur 1 seule fonctionnalitée...

[manzeki]

Je pense qu'en génie informatique tout ne peut se résumer à l'assemblage de librairies.
Le paradoxe est que pour developper une librairie de qualité, on doit maîtriser les couches de bas niveau.
C'est dommage que pour le cas du Web, beaucoup pensent être développeurs pour peu qu'ils sachent installer wordpress.

[Guikingone]

L'éternel débat de savoir s'il faut partir de zéro, au fond, la question revient à un simple raisonnement, si on utilise des librairies, les créateurs de ces librairies sont bien partis de zéro, donc nous partons bien d'un point zéro avec cette librairie.
Ce qui amène à la question suivante, que signifie zéro aujourd'hui ?

Personnellement j'utilise des librairies tierces et je ne m'en plaint, je découvre de nouvelles approches et solutions à un problème récurrent, ce qui au fond, me permet d'être plus productif et plus à même de résoudre le problème que je rencontre.

[Lcf.vs]

Voilà un sujet sur lequel je ne puis m'empêcher d'intervenir... ^^'

Fort de mes nombreuses années à aider du monde, notamment ici, je remarque de plus en plus qu'ingénieur ou non, les gens n'apprennent plus à maîtriser un langage, ni même une logique algorithmique.

Bien souvent, en effet, ils utilisent des bibliothèques sans même savoir si c'est le plus approprié, si cela est justifié (je ne compte plus le nombre de fois où j'ai lu des aidants suggérer à des débutants d'utiliser jQuery pour faire une bête requête AJAX).

En surcouche, la plupart ne lisent pas les documentations et, encore moins, les spécifications... fonctionnant majoritairement au try... catch et venant, ensuite, demander de l'aide, "paskesamarchpas".

Le développeur from scratch n'existe presque plus... pourtant, souvent, le code fait-maison (s'il est bien fait) sera plus performant qu'une lib' cherchant généralement à s'adapter à un maximum de besoins, souvent très loin des nôtres, dégradant soit les perfs, soit la qualité produite, soit les deux. Suffit de voir la qualité sémantique des pages produites par les principaux frameworks web, à moins de tout surclasser.

Mais je pense qu'il est intéressant de soulever un autre aspect énoncé dans cet article: le fait qu'on s'intéresse de moins en moins à la façon dont les outils qu'on intègre partout fonctionnent.

On ne cherche plus à avoir confiance en un outil, on l'utilise parce qu'il nous fait gagner du temps et on cherche pas plus loin, "pas le temps"...

Et c'est ainsi qu'on se retrouve avec des serveurs infectés, des applications qui nous surveillent (ou surveillent les clients de l'entreprise dans laquelle on bosse), qui volent des données, qui embarquent des ransomwares, etc.

Dernier exemple en date que j'ai pu constater : Intel XDK qui embarquait un trojan, par le biais d'un module externe embarqué (sur une version d'il y a quelques mois).

À bon entendeur.

[RyzenOC]

C'est un peu l'objectif d'un informaticien ans une entreprise: Fournir un logiciel qui réponds à un besoin rapidement.
On as tous (ou presque) la volonté de vouloir faire un logiciel parfait, mais voila un projet limité dans le temps et financièrement. J'ai pas honte de le dire, moi même j'ai du m'y mettre au développement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 try:
   #mon instruction
catch:
   pass

Et encire pour aller plus vite j'ai du abandonner les langages bas niveau, pour me consacrer uniquement à du très haut niveau (même java c'est trop long), je code en python uniquement, sa me permet de faire un code rapidement et multi-plateforme.

Le c++ c'est bien, mais c'est trop long pour codé le moindre truc.

Et encore une chose, on vit dans un monde qui évolue a chauqe minute, il n'est pas rare de ma boite me demande rajouter une fonctionnalité qui n'étais absolument pas prévue au départ, il faut donc faire du code flexible, utiliser des bibliothèques qui fournisse un besoin très large et donc indispensable.