Le 15 oct. 2013 à 11:29, Raphael Maunier a écrit : > > On Oct 15, 2013, at 11:18 AM, Emmanuel Thierry <m...@sekil.fr> wrote: > >> >> Le 14 oct. 2013 à 23:38, Raphael Maunier a écrit : >> >>> >>> On Oct 14, 2013, at 11:21 PM, Kavé Salamatian >>> <kave.salamat...@univ-savoie.fr> wrote: >>> >>>> >>>>> >>>>> Dans la vrai vie, celle qui fait vraiment tourner Internet, tu ne peux >>>>> pas mettre en péril ton backbone, juste pour faire mumuse avec la >>>>> solution brillante de l'ingénieur. >>>> >>>> Bas non un vrai ingénieur ne fait jamais mumuse, mais il se fait pas aussi >>>> rouler dans la farine par un commercial qui lui vend la solution du >>>> siècle. L'ingénieur brillant est l'ingénieur qui est capable de dépenser >>>> 100 k€ pour répondre à son besoin (ou au besoin de son entreprise) car il >>>> n'y a pas de solution moins cher qui répondrait à toutes les contraintes >>>> doit celle que tu décrit, mais qui est aussi capable d'implanter la >>>> solution à 500 € qui répond au besoin sans penser que cela réduira mon >>>> importance dans la boite (car fréquemment c'est le volume de fric que tu >>>> gaspille qui défini ton importance dans la boite). Ce n'est pas le prix >>>> d'une solution qui valide sa qualité technique. j'ai un peu l'impression >>>> qu'on a oublié dans la profession qu'on fait un boulot d'ingénieur, pas de >>>> chargé d'achat de matériel informatique. >>> >>> Tu dois confondre entre l'ingénierie et la direction technique. >>> L'ingénierie teste et valide les solutions des constructeurs ou opensource, >>> et s'il y a le budget pour libérer du temps humain, des solutions "interne" >>> et assume également la fonction de R&D >>> >> >> L'ingénieur réseau se contente de tester toute la journée ? C'est triste, >> quel gachis d'intelligence... >> A tel point qu'à ce que j'ai l'impression, si l'ingénieur réseau doit ne >> serait-ce qu'écrire une seule ligne de code il va appeler ça de la R&D. Chez >> nous en informatique on appelle ça de l'intégration. > > Attention de ne pas interpréter mes propos. > Il teste et valide les solutions en fonction des problématiques interne et > des clients. C'est de l'ingénierie pure. > > Si pour automatiser qq éléments de conf, l'ingénieur est capable de le faire, > et il est forcement invité à le faire, par contre Si tu veux du code, il faut > un dev qui le fera proprement. > > Le code crado, non documenté parce que fait à l'arrache, c'est > malheureusement bien trop souvent un soucis quand un mec se barre. >
Quand tu vas voir le SDN arriver dans ton réseau, tu verras, ce n'est *que* du code. Il va falloir commencer à apprendre à coder justement ! ;) Du petit bout de ma lorgnette, je vois surtout qu'un ingé réseau qui ne sait pas coder ne saura se restreindre qu'à des solutions propriétaires (voire des environnements propriétaires, on le voit bien en sysadmin sur les environnements tout intégrés Microsoft). Il sera incapable de voir qu'avec un peu de script, ou de C (bouh, le gros mot ! ), il est capable d'adapter sa solution propriétaire pour qu'elle fasse *exactement* ce qu'il veut. Et il aura tendance à considérer ce manque comme un atout: si j'achète tout Cisco (y compris les DHCP, DNS &cie), ce n'est pas parce que je ne sais pas intégrer autre chose à mon environnement, c'est parce que Cisco est le meilleur (en plus vu le prix auquel ils vendent ça ne peut qu'être top moumoute ! ;) ). Cordialement Emmanuel Thierry --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
