Au fil du temps, j’ai pu observer des lacunes techniques chez beaucoup d’informaticiens. On ne peut évidemment pas tout savoir ; l’informatique est un domaine très large, qui couvre des choses très variées. Mais il y a un certain nombre de connaissances basiques que vous devez absolument maîtriser si vous êtes informaticien.
Valeurs binaires standard
Il me semble absolument nécessaire de connaître de tête les plus importantes valeurs binaires.
Un octet, c’est stocké sur combien de bits ? Et un entier standard ?
Combien peut-on stocker de valeurs différentes en 8 bits ? Et en 16, 24, ou 32 ?
Réponses :
- Un octet est stocké sur 8 bits. Un entier standard est stocké sur 32 bits. Un «short» est classiquement stocké sur 16 bits, un «long» sur 64 bits.
- En 8 bits (sur un octet, donc), on a 256 valeurs différentes. En non-signé, cela va donc de zéro jusqu’à 255. En signé, cela va de -128 à +127.
- En 16 bits (sur 2 octets), on a 65 536 valeurs. De zéro à 65 535 en non-signé ; de -32 768 à +32 767 en signé.
- En 24 bits (3 octets), on a 16 777 216 valeurs possibles.
- En 32 bits (4 octets), on a 4 294 967 296 valeurs possibles.
- En 64 bits (8 octets), on a 18 446 744 073 709 551 616 valeurs.
C’est pas bien compliqué à mémoriser. Gardez juste à l’esprit les ordres de grandeur :
- 1 octet => 256
- 2 octets => 65 mille
- 3 octets => 16 millions
- 4 octets => 4 milliards
- 8 octets => beaucoup (je considère que 18 trillions, ça fait trop grand pour être compté).
Mais pourquoi est-ce si important à savoir ? Après tout, on peut recalculer facilement tout ça. Oui, mais pour un informaticien, recalculer ça reviendrait au même qu’un géomètre qui se demande tous les jours combien il y a de centimètres dans un mètre…
Concrètement, ces valeurs ne servent pas forcément tous les jours, mais il faut être capable de les utiliser à bon escient. Si vous faites du développement embarqué, vous aurez sûrement besoin de calculer au plus juste l’utilisation de la mémoire ; et en codant en C, vous devrez choisir le type de vos variables en connaissance de cause. Mais ce n’est pas le seul cas où c’est utile.
Si vous êtes un développeur Web ou un DBA vous aurez à créer des tables dans votre base de données. Pour cela, vous devez connaître les types de données que vous pouvez utiliser. Si on prend l’exemple de MySQL, les nombres entiers peuvent être stockés dans des champs de type TINYINT, SMALLINT, MEDIUMINT, INT et BIGINT. Chacun pouvant être signé (par défaut) ou non-signé (en ajoutant UNSIGNED au type).
Alors pour stocker la taille d’un être humain, en centimètres, un TINYINT UNSIGNED sera sûrement suffisant. Hum… sauf si vous devez gérer les 4 hommes les plus grands du monde qui dépassaient les 255 centimètres. Certains choisissent alors la facilité et stockent tous leurs entiers en utilisant des INT. Mais pourquoi prendre 4 octets, là où la moitié suffirait ?
De la même manière, quel est le type le plus adapté à une clé primaire ? Sur 16 bits, ce serait un peu court ; c’est assez fréquent d’avoir des tables qui contiennent bien plus de 65 milles lignes.
Un petit truc pour y arriver, c’est de réfléchir en terme de rapidité de remplissage de la table : Si vous avez en moyenne une nouvelle ligne par seconde, une clé primaire stockée sur 3 octets (un MEDIUMINT UNSIGNED) se remplira en à peine plus de 6 mois. Si par contre vous passez sur 4 octets (INT UNSIGNED), vous pouvez tenir ce rythme pendant 136 ans. Est-ce vraiment utile de passer sur un BIGINT ?
Langage de script
Quel que soit votre domaine, quelle que soit votre plate-forme, quelles que soient les technologies que vous utilisez, vous ne pouvez pas faire votre travail efficacement si vous ne connaissez aucun langage de script. Évidemment, on peut toujours s’en tirer en mettant au point des «méthodes de contournement». Mais quelle perte de temps ! Cela revient à passer le baccalauréat scientifique avec une calculatrice « 4 opérations » ; c’est possible, mais c’est se mettre soi-même des bâtons dans les roues.
Par «langage de script», j’entends n’importe quel langage de programmation qui permet de faire des petits outils, des coder des prototypes, de faire la « glue » entre d’autres programmes. Il ne faut pas avoir besoin de sortir son compilateur à chaque fois qu’on veut faire un petit programme qui va nous simplifier la vie de manière ponctuelle.
- Si vous travaillez sous Unix, vous devez avoir au moins quelques notions de base en Shell. Le minimum, c’est de pouvoir instancier l’exécution d’un programme, d’en récupérer le résultat et de le transmettre de manière conditionnelle à un autre logiciel.
- La plupart des langages de script sont très versatiles. Perl, Python, Ruby, PHP, … Souvent on n’y pense que dans le cadre d’un développement Web. Et pourtant, ils permettent de faire tellement de choses qu’il serait idiot de ne pas en maîtriser au moins un.
- Si vous êtes sous Windows, n’oubliez pas que vous pouvez automatiser la plupart de vos traitements avec du VBScript, voire du Javascript.
Programmation orientée objet et assimilé
Quel que soit le domaine informatique dans lequel vous évoluez, vous devez absolument connaître les principes de base de la programmation orientée objet. Même si vous n’êtes pas développeur, soit vous allez prendre part à des choix techniques, soit vous aurez à suivre des discussions techniques. Et même si vous utilisez un langage procédural, ou que vous choisissez de ne pas utiliser toutes les capacités « objet » d’un langage donné, cela reste valable : Il vaut mieux connaître un minimum ce qu’on choisit de ne pas utiliser, sinon on fera forcément un mauvais choix un jour.
Les concepts-clés ne sont pourtant pas nombreux :
- Le principe de l’objet, qui est une «boîte noire» qui regroupe ses données et les traitements qui vont s’y appliquer.
- L’héritage et la surcharge, qui permettent de créer un type d’objet qui dérive d’un autre en l’enrichissant.
- La portée des attributs (les données d’un objet) et des méthodes (ses fonctions), qui permet de les rendre accessibles à tout le reste du code, ou de les réserver à un usage « interne ».
Vous devez maîtriser ces concepts. Sinon, à chaque fois que quelqu’un vous demandera «Pourquoi tu ne fais pas un objet comme ceci ou comme cela ?», vous aurez l’impression de passer pour un abruti.
Il y a d’autres concepts qui accompagnent la programmation orientée objet. Considérez-les comme du bonus, sauf un : les exceptions. Il s’agit d’un concept « disruptif » dans la gestion des erreurs. Les développeurs ont généralement besoin d’un peu de temps pour en intégrer tous les aspects ; mieux vaut s’y préparer avant d’avoir besoin de s’y frotter au boulot.
Filesystem Hierarchy Standard
Vous pouvez faire le choix de carrière de ne jamais toucher à un système Unix de près ou de loin (ce qui inclus Linux et Mac OS X, sans oublier Solaris ou AIX), sachant que ça veut dire que vous souhaitez travailler exclusivement sous Windows. C’est un choix qui se défend, mais à l’échelle d’une carrière entière, c’est quasiment aussi discutable que l’inverse. La raison est bien simple : sur un nombre non négligeable de projets, l’environnement de production est sous Unix, même si l’environnement de développement est différent. Il est important de prendre cela en compte.
Le minimum pour se sentir à l’aise sur un système Unix, c’est de comprendre l’organisation du système de fichiers, pour comprendre à quoi sert chaque répertoire sur le disque et pouvoir retrouver un fichier au besoin. Ce n’est pas difficile à intégrer, il vous faudra une petite demi-heure pour lire la documentation, et encore moins pour lire le résumé en français sur Wikipédia.
Le minimum à savoir :
- /boot : Fichiers nécessaires au démarrage du système.
- /bin : Programme exécutables de base.
- /sbin : Programmes exécutables du système.
- /etc : Fichiers de configuration.
- /home : Répertoire parent des répertoires personnels.
- /usr : Fichiers supplémentaires (contenant lui-même des répertoires bin/, etc/, …).
- /usr/local : Logiciels compilés en local (contenant à nouveau les répertoires bin/, etc/, …).
- /tmp : Fichiers temporaires.
- /var : Données variables non temporaires.
- /opt : Logiciels optionnels.
SQL
Quoi ? Le SQL ferait partie des connaissances de base en informatique ? C’est nouveau, ça ?
Eh bien oui, c’est relativement nouveau. Il y a une dizaine ou une quinzaine d’années, ça aurait été différent. Mais de nos jours, il paraît compliqué de vraiment y échapper. Bien entendu, je pense tout d’abord au développement Web. C’est devenu une industrie difficile à négliger. Ce serait dommage qu’à un moment ou un autre de votre carrière, vous soyez coincé le jour où on vous demande de modifier l’enregistrement d’un formulaire sur l’intranet de l’entreprise…
Mais même en dehors du Web, le SQL prend une place de plus en plus importante. Je pense notamment à tous les logiciels qui intègrent SQLite comme support de stockage interne. Même pour un programme standalone, la possibilité d’enregistrer des données relationnelles est vraiment pratique en comparaison aux alternatives utilisées jusqu’alors.
En imaginant que ce n’est pas votre cœur de métier, et que vous pourrez toujours apprendre − le moment venu − à créer des bases ou des tables, il n’en reste pas moins que vous devez savoir comment écrire les 4 types de requêtes SQL fondamentales :
- SELECT : récupération de données
- INSERT : ajout de données
- UPDATE : mise-à-jour de données
- DELETE : effacement de données
Et le reste
Ah, il y a encore plein de choses qui me semblent nécessaires et obligatoires, même si un peut moins fondamentales :
- Un minimum de connaissance du HTML.
- Connaître les bases des outils de bureautique (traitement de texte et tableur). Savoir faire un tableau croisé dynamique sous Excel ou OpenOffice vous sauvera parfois d’un long développement pour générer des statistiques.
- Savoir utiliser Google Alerts pour faire une veille passive des sujets qui vous intéressent, que ce soit dans un domaine technique ou pour surveiller les annonces de vos concurrents.
Et vous, qu’est-ce qui vous semble important de savoir ?
C’est fortement dépendant de l’investissement qu’on souhaite mettre dans son métier ou sa passion, de comment on y est entré, de ou on souhaite aller, etc. Mais globalement je suis d’accord avec toutes ces bases que tu exposes.
On pourrait probablement en rajouter dans d’autres domaines, comme l’administration système et réseau, savoir faire quelques commandes de bases pour connaitre ses paramètres réseaux et/ou l’état de son système. Au dela de google alerts, simplement savoir utiliser google, ou un autre moteur de recherche pour se dépatouiller d’une situation bloquante, ou au moins se rassurer qu’on n’est pas seul dans ce cas… et plus globalement, savoir trouver de l’info ou de la documentation sur internet et/ou ses différents réseaux.
Sinon, tu aurais pu appeler ton article « Culture générale informatique ». Comme pour la culture générale, il y a des gens qui en ont et qui le savent, d’autres qui étalent le peu qu’ils ont, comme pour la confiture (j’en connais !) 😉
Et il y les gens comme moi, qui se situent humblement entre les deux. Cela dit, je ne sais pas faire de tableaux croisés dynamiques sous un tableur, je n’ai jamais eu besoin de m’y pencher et surtout pas la moindre envie.
Suis-je pour autant à exclure du clan des informaticiens ?
Je pense que tu as omis un domaine d’importance, pour tous les informaticiens sur des projets « web » au sens large (ie des projets ou il y a du réseau).
Avoir des connaissances de base sur comment fonctionne un reseau, udp, tcp/ip, etc.
@Bob : Hum, je dépasse la «culture générale informatique», là. Entre le binaire et le SQL, c’est quand même un peu pointu.
Pour le coup, je suis moi aussi une quiche en bureautique (comme toi : pas envie). Mais le fait de savoir que ça existe m’a vraiment déjà épargné des heures de codage de stats.
@Loïc : Je suis tout à fait d’accord avec toi. Mais je ne voulais pas donner à mon post une « teinte Web » trop marquée.
Il n’empêche, de nos jour, il est important d’avoir un minimum de connaissances en TCP/IP. Être capable de configurer un petit réseau, de comprendre les mécanismes d’adressage, savoir à quoi sert un routeur, comprendre le client/serveur (eh oui, il y a des gens qui ne comprennent pas le concept !), connaître les différences entre TCP et UDP, …
@bob : dépendant de l’investissement que l’on souhaite mettre dans son métier ou sa passion?
Déjà on parle de bases ici, donc investissement… Si tu souhaites investir moins dans ton métier d’informaticien, fais cordonnier, tu rendras service aux infortunés qui travaillent avec toi ( quand je dis « tu », cela ne s’adresse pas à toi, bien entendu).
savoir faire un tableau croisé dynamique sous excel n’a rien a voir avec le fait d’être informaticien. En 10 ans, je n’en ai jamais eu à faire.
OK, les gars, on arrête de s’exciter sur les tableaux croisés dynamiques, hein. J’ai mis ça au même niveau que savoir utiliser Google Alerts… Je voulais surtout signifier qu’il y a des petites choses qui, sans être absolument vitales, peuvent contribuer à nous simplifier la vie.
Il n’empêche, Loïc, que quand on bossait ensemble, il y a certaines stats que Marcel générait par ce moyen, ce qui m’a économisé par mal d’emmerdes dans le code.
Tiens d’ailleurs, je ne me suis jamais servi de google alert non plus 😉
En fait, je pense qu’au delà de certaines bases évoquées ci-dessus, il faut surtout savoir apprendre encore et toujours et savoir se remettre en question quand la situation l’exige. C’est valable dans tous les domaines…
Tout à fait. D’où l’importance de la veille technologique (au niveau personnel) et de la R&D (au niveau de l’entreprise).
Plutôt d’accord avec ta liste mais ça manque un peu de hiérarchisation et logique à mon goût, bon c’est juste la présentation, rien de dramatique ;-).
J’ajouterai quand même 2 notions essentielles pour moi:
– les design pattern (histoire de ne pas tout réinventer à chaque fois)
– la gestion de configuration (essentiel pour travailler en équipe et gérer la maintenance/évolution)
Les design patterns, pourquoi pas. Ça fait effectivement partie des premiers trucs que je fais lire à mes développeurs. Mais je ne pense pas que ce soit des connaissances qui servent à tous les profils d’informaticiens, c’est quand même exclusivement lié au développement. Mon post visait une certaine « universalité ».
Qu’est-ce que tu entends exactement par « gestion de configuration » ?
Très bon article !
Je suis d’accord à quasi 100%.
J’ajouterai :
– utilisation d’un outil de gestion des sources (subversion, git, …), ou au moins les concept de base et ses avantages
– quelques notions de sécurité (gestion des mots de passe, ftp/telnet c’est mal, …)
– notions sur le fonctionnement du Web (DNS, qu’est-ce qu’un serveur web, pourquoi les cookies ?, …)
– faculté à apprendre à apprendre
Bonnes remarques, Franek. C’est vrai que j’aurai dû penser aux concepts de base de tous les outils de gestion de source.
Les notions de sécurité sont aussi assez importantes. Si on néglige ces aspects, ils sont difficiles à réintégrer après coup, que ce soit dans un développement ou une infrastructure réseau.
« c’est quand même exclusivement lié au développement » -> heu les valeurs binaires aussi non ?
la gestion de configuration inclus la gestion des sources, voir http://fr.wikipedia.org/wiki/Gestio…
Pendant que j’y suis j’ajoute la connaissance de cycle de développement (en V par ex.)
Non, justement, j’explique que les valeurs binaires ne sont pas liées uniquement au développement. Un administrateur système en aura besoin, ainsi que toute personne devant approcher une base de données.
Merci pour le lien sur la gestion de configuration. C’est intéressant, mais je ne sais pas si ça doit vraiment faire partie des “connaissances informatiques de base”. Après, c’est sujet à discussion.
Pour les cycles de développement, c’est vrai qu’il est difficile de faire correctement son boulot d’informaticien sans en avoir la moindre notion.
Ho ho !
Tu t’es lancé dans un sujet périlleux car relativement subjectif.
Il peut y avoir pas mal de points de vue différents sur les connaissances de base.
Du mien (qui n’engage que moi), la partie sur la taille des données me parait évitable. Sauf dans le cas des systèmes embarqués comme tu le dis.
Le prix du Ko est tellement dérisoire aujourd’hui qu’on peut se permettre de tailler large ses variables et autres champs de BdD.
Je pense qu’il aurait été moins risqué d’énoncer une liste un peu plus complètes des différents domaines de compétence en s’épargnant les détails et exemples. Et en laissant le lecteur se faire ses propres recherches.
@draudrau : Ton commentaire est un peu couillu, Olivier. À quoi servirait d’écrire un blog, si ce n’est pour y partager mes opinions et mon expérience ? Si c’était juste pour fournir des liens et «laisser le lecteur se faire ses propres recherches», j’aurais déjà laissé tomber ; Wikipédia a un portail informatique qui me surpassera toujours à ce jeu là.
Et si je veux prendre le temps d’expliquer les notions qui me semblent importantes, je ne vois pas pourquoi je devrais m’en priver…
Je reste sur ma position quant à la connaissance des valeurs binaires standards. Un informaticien qui n’y connait absolument rien fera forcément un mauvais choix un jour ou l’autre. Un peu comme un pâtissier qui ne connaîtrait pas par cœur la différence entre du sucre vanillé et du sucre-glace, ou un cuisinier qui ne ferait pas la différence entre du sel et de la fleur de sel. Ça fera illusion pendant un certain temps, peut-être même très longtemps ; mais ce n’est pas comme ça que j’aborde mon boulot.
L’excuse du «le stockage est gratuit» est répandue mais reste un mauvais calcul. La taille des données n’a pas qu’une conséquence de coût de stockage. Stocker tous tes entiers sur 64 bits en base de données, sans bonne raison, peut amener à des problématiques de performance indémerdables. Sans parler des questions soulevées par la moindre architecture répliquée ou répartie.
Après, tout dépend des buts qu’on se fixe. Mais si on veut faire un travail (de développement, d’administration de bases de données, d’architecture système) propre, performant et pérenne dans le temps, ça me paraît nécessaire.
Bonjour,
Les prérequis que vous indiquez ne peuvent en effet pas faire de mal mais les considérer comme incontournable pour tout informaticien… me semble limiter le métier d’informaticien à programmeur ou administrateur système/réseau. Qu’en est-il des informaticien qui réparent les ordinateur en panne ? ou de bien d’autre métier estampillé « informaticien » qui s’éloigne soit de la technique soit du software ?
Sinon je rajouterais bien là dactylo aux prérequis ou tout du moins aux recommandations pour tout informaticien 😉
PS : désolé du déterrage sauvage de billet d’il y a 3ans !
@GammaNu : C’est vrai que ma vision du métier d’informaticien se fait forcément à travers le prisme de ma propre expérience. Et c’est donc, s’il faut coller des étiquettes, celle du métier d’ingénieur informaticien plutôt que de celui de technicien informatique (soit dit sans aucun jugement de valeur).
Je suis d’accord, quelqu’un qui répare les ordinateurs aura rarement besoin de connaître le SQL. Mais comme ce genre de prestation est souvent associée à des activités annexes – comme de la création de sites web vitrines, par exemple – cela peut rester important sans être vital.
Bonjour,
très bon article, ça m’a permis de me remettre en question et de revoir en profondeur les points évoqués (même si déjà vu en cours de route entre la L1 et le Master). @raf effectivement, sur la notion de cycle de vie d’un projet, de la gestion de projet c’est un point de plus qui peut aider à comprendre les rapports client-fournisseur.
Alors tout à fait d’accord, ça me parait être les bases, vu que je débute et que c’est à peu près ce qu’on m’a appris + du java et du python et des frameworks. Personnellement j’aurais pensé que la maitrise d’au moins 4 ou 5 langages était nécessaire. Et j’aurais cru qu’il existait des langages incontournables (je ne parle pas de SQL ou HTML, j’ai du mal à les considérer comme des langages, ça n’a pas la difficulté de java par exemple, où il faut plus d’une journée pour faire des choses). J’avoue avoir un peu de mal à savoir quoi faire en attendant de trouver un travail car de toutes façons l’environnement de travail n’est pas prévisible à l’avance.
Voici les langages que je bosse : java, python, javascript. A votre avis qu’est-ce qu’il faudrait que j’ajoute ? J’aimerais un langage différent, car ceux ci reposent grosso modo sur les mêmes principes. Mais vu qu’il y en a plus de 50, je n’aurais pas le temps de tous les voir.
Par contre un truc me dérange profondément dans ma formation : je n’ai jamais rien vu sur le réseau ou le hardware. Est-ce qu’il y aurait de bonnes références pour rattraper mes lacunes ? (j’ai de vagues notions de bases suite à quelques recherches sur internet, mais trop lèger et rien de construit ni à peu près complet)
@Egg : Vaste sujet. Pour augmenter ton employabilité, tu peux apprendre un autre langage comme le PHP. Dans tous les cas, il faut que tu connaisses très bien le SQL si tu veux faire du développement web, ainsi que le HTML et le CSS. Tu peux aussi approfondir le développement front-end, en étudiant un framework Javascript comme Angular. Tu peux passer au développement mobile, avec Ionic et Phonegap/Cordova, ou carrément le développement natif en Java (Android) ou ObjectiveC/Swift (iOS).
Avoir des notions réseau est nécessaire, sans pour autant verser dans l’administration système (même si un minimum de connaissances en administration système est utile ; être capable d’installer un petit serveur pour faire du développement web, c’est très pratique et valorisable). Par contre, si tu veux faire du développement logiciel, tu t’en fous un peu du hardware.
Merci pour la réponse rapide, j’ai un peu travaillé avec AngularJS, du coup je vais approfondir, je pense que je ne l’avais pas bien utilisé. Le HTML et le CSS? j’ai ds bases, mais j’avoue que ce n’est pas ma passion ^^. Et j’ai fait un peu d’Android aussi. Par contre, je ne connais pas les autres que tu cites, je vais me renseigner là-dessus. Qu’est-ce que tu appelles installer un petit serveur pour faire du développement web, forcément il faut un serveur non ? Pour java avec eclipse j’utilise un serveur tomcat, c’est ça ? Oui il s’agit d’autre chose ?
très bon article, j’ai aimé les idées, la façon d’écriture, tout est compréhensible. Merci infiniment pour votre effort.
Super article comme d’hab!
Bravo et bonne journée