de la modernité et du travail
A la dernière conférence sur la sécurité, à l’ECE, Franck Dubray, patron d’intrinsec nous racontait comment en informatique avait progresser le métier d’ingénieur. En électronique, c’est pareil …
Ce que disait Franck Dubray, c’est qu’il y’a 8 ou 10 ans, il fallait un ingénieur pour installer et configurer un firewall, aujourd’hui, il n’y a pas besoin de diplôme pour ça.
L’électronique aussi a beaucoup évoluée. Je me suis fait cette réflexion en cours de VHDL.
En effet, pour conçevoir un circuit numérique, il faut réfléchir aux portes logiques à combiner pour faire ce circuit. Mais maintenant, comme cette étape est jugée longue et laborieuse, nous avons inventer les puces programmables. Ces puces permettent de combiner automatiquement des portes logiques selon les instructions déduites à partir d’un code source (du VHDL dans mon cas, mais d’autres existent).
Néammoins, coder est une activité quelque peu barbante. Du coup, un système a été inventé pour générer du code à partir d’un graphe d’état, en fait, un dessin tout à fait banal.
Les bienfaits de la technologies permettent donc de se reposer
Hélas, non. En réalité, cela permet de dégager du temps pour une activité encore plus productive.
Vive le progrès et la créativité.









Et avec l’arrivée de l’executive UML on pourra bientot tester des routines juste en dessisant des graphes.
Pour l’électronique, au dessus du VHDL, il y a le SystemLog et le SystemC, qui ont un niveau d’abstration supplémentaire.
Cette évolution est nécessaire pour pouvoir réaliser des systèmes de plus en plus complexes qui souvent utilisent les memes routines. Pas la peine de reinventer la roue à chaque projet…
Mais n’oublie pas qu’un ingénieur d’études doit etre capable de maitriser sa production de bout en bout et donc de pouvoir mettre les mains dans le cambouis (assembleur,C…) à l’occasion.
Un aute intéret : la standardisation.
Dans un monde globalisé, ou des équipes de différentes nationalités travaillent ensemble (collaboration ou récupération de projets…) il faut pouvoir se comprendre.
Un dossier UML bien rédigé sera toujours plus clair qu’un code source, ausi commenté qu’il soit.
Leave your response!