LO
Systèmes d'information
Vous forme à faire tourner et à modifier des systèmes écrits par d'autres : à découvrir ce qu'une organisation possède déjà, ce qui dépend de quoi, ce qu'un enregistrement a le droit d'y signifier, et ce qui casserait si vous en éteigniez un.
Choisissez un système que vous pouvez réellement atteindre — celui d'une association, d'un employeur à temps partiel, de votre département — et dessinez ce à quoi il est raccordé en interrogeant les gens plutôt qu'en lisant la documentation. Comptez les raccordements que personne n'a su nommer. Ce décompte est la seule chose de cette page que personne ne peut générer à votre place.
Un chiffre unique pour toute une filière cacherait ce qui compte : ce diplôme forme plusieurs compétences distinctes, et elles ne vont pas toutes dans le même sens. L'automatisation agit sur des tâches : toute évaluation vit donc sur les pages métier ci-dessous — pas ici.
Écrit pour les licences appelées diversement systèmes d'information, informatique de gestion ou management des systèmes d'information — celles que l'on trouve d'ordinaire dans une école de gestion et bâties autour des systèmes qu'une organisation achète plutôt que de ceux qu'elle écrit. Un cursus portant le même nom à l'intérieur d'une faculté d'informatique est souvent de l'informatique avec une mineure en gestion, et ses diplômés atterrissent ailleurs. Une chose que cette page ne peut pas généraliser compte plus que la maquette : finissez-vous à l'intérieur de l'organisation qui exploite les systèmes, ou du côté d'un éditeur, d'un cabinet de conseil ou d'un infogérant, puisque ces trois-là vendent précisément le travail que la première essaie de garder. Notez aussi que la plupart des gens qui font ce travail sont employés par une banque, un hôpital ou une usine et non par une entreprise informatique, si bien que les statistiques sur l'emploi du secteur technologique ne les voient pour l'essentiel pas.
Ce que ce diplôme forme réellement#
Pas la liste des cours — les compétences en dessous, et si chacune vaut plus ou moins qu'avant.
Savoir ce que l'organisation fait déjà tourner
Vaut plus qu'avantQuels systèmes détiennent quels enregistrements, lequel fait foi quand deux d'entre eux se contredisent, ce qui est raccordé à quoi, et cette intégration que quelqu'un a construite en 2019 avant de partir.
C'est l'entrée qui n'est pas devenue moins chère alors que tout autour d'elle le devenait. Écrire le code d'intégration fait partie de ce que ces outils réussissent le mieux ; savoir lequel de quatre systèmes détient la version qui fait foi d'un enregistrement, et quel champ ment discrètement, loge dans des gens présents depuis des années et n'est écrit à peu près nulle part. Un banc d'essai de texte vers SQL construit à partir de journaux de requêtes d'entrepôts de données d'entreprises réelles, et non de jeux de données publics, dit la même chose par l'autre bout : un modèle de langage brut y a obtenu zéro, contre quatre-vingts à quatre-vingt-dix pour cent sur les bancs d'essai publics, et les raisons avancées étaient structurelles : les schémas réels pourrissent jusqu'à comporter plusieurs colonnes du même nom, et chaque parc applicatif porte son parler local.
Traduire entre le côté métier et le côté technique
Vaut moins à lui seulTransformer ce qu'un responsable dit vouloir en quelque chose sur quoi un ingénieur peut agir, et retransformer une contrainte technique en un choix qu'un responsable peut réellement faire.
C'est l'argument de vente le plus ancien de cette filière et c'est en plein ce qu'un outil de rédaction réussit le mieux : décrire un flux de travail avec des mots et récupérer les objets, les règles et la spécification est dans le champ de ces outils. Ce qui n'est pas devenu moins cher, c'est de savoir laquelle des étapes décrites les gens sautent en réalité, et pourquoi — cela s'apprend en regardant une équipe travailler, pas en lisant le document de processus. La traduction doit donc toujours avoir lieu et elle ne paie plus toute seule. Elle paie quand la personne qui la fait connaît aussi le parc applicatif.
Produire l'expression de besoin, la cartographie de processus et le rapport
Vaut moins à lui seulLa production écrite de la filière : cahiers des charges, schémas de processus, plans de test, requêtes et tableaux de bord.
Chacune de ces choses est un texte structuré dont le résultat est vérifiable, et c'est cette propriété qui permet à un outil de rédiger, d'échouer et de rédiger à nouveau sans personne pour regarder. L'interrogation en langage naturel et la génération de graphiques sont déjà intégrées aux produits qu'utilisent les analystes. Deux conséquences en découlent et ce n'est pas la même : rédiger cesse d'être ce pour quoi on vous paie, et le nombre de brouillons augmente — les heures passent donc de produire ces documents à trouver celui qui est désormais faux et à discuter avec la personne qui le cite.
Dire ce qu'un enregistrement a le droit de signifier
Vaut plus qu'avantDécider quelle version d'un client, et dans quel système, est la vraie, ce que veut dire une valeur de statut, qui a le droit de la poser, et écrire cela en deux phrases que les deux personnes qui s'en servent acceptent toutes les deux.
L'interrogation en libre-service ne produit de bonnes réponses que par-dessus des définitions que quelqu'un entretient : le travail rare passe donc de répondre aux questions à entretenir la couche depuis laquelle tous les autres répondent. Cela a aussi cessé d'être seulement une bonne habitude interne : depuis août 2026, un déployeur d'un système à haut risque dans l'UE qui contrôle les données d'entrée doit s'assurer que ces données sont pertinentes et suffisamment représentatives. Ce devoir tombe sur la partie qui exploite le système, pas sur celle qui l'a construit, et les destinations de cette filière sont toutes du côté de l'exploitation.
Tenir un système construit par quelqu'un d'autre
Se maintientParamétrer une plateforme achetée, puis vivre avec le paramétrage : la règle ajoutée l'an dernier et fausse aujourd'hui, le champ que personne ne remplit, l'autorisation accordée une fois pour une raison que personne n'a consignée.
La moitié construction est devenue bien moins chère et la moitié maintien a grossi par exactement le même mécanisme : chaque règle ajoutée est une règle qui sera fausse plus tard et qu'il faudra retrouver, si bien que paramétrer plus vite produit plus de paramétrage plutôt que moins de travail. Les heures ne disparaissent pas, elles passent de construire à démêler, et démêler est invisible sur une feuille de route. C'est pour cela que ceci se maintient au lieu d'être une économie — et pour cela que c'est la part du poste à laquelle on donne un budget comme si elle avait été supprimée.
Où cela peut mener#
Plusieurs directions, jamais une seule. Chacune dit ce que votre formation réemploie, ce qui manque généralement aux diplômés, les conditions d'entrée réelles, et une chose que vous pouvez tester ce semestre.
Être responsable du système dans lequel l'entreprise tourne
analyse au niveau de la tâche →- Ce qui se transfère
- Presque tout, et c'est ce que cette filière a de plus proche d'un chemin direct : paramétrer une plateforme achetée, garder ses enregistrements dignes de confiance, décider ce que son automatisation a le droit de faire sans personne dans la boucle, et être celui qui sait lesquels des chiffres qui en sortent sont solides et lesquels tiennent par une hypothèse.
- Ce qui manque généralement aux diplômés
- Les diplômés arrivent capables de paramétrer et incapables de tenir une ligne. La contrainte propre de ce métier est que le poste a d'ordinaire la connaissance et pas l'autorité : quand l'équipe qui porte le chiffre du chiffre d'affaires veut que l'automatisation envoie davantage, la personne qui peut dire non est plus haut. Se faire désavouer à répétition est la façon dont une frontière s'érode sans qu'aucune décision ne soit jamais consignée, et rien dans un cursus ne répète cela.
- La réalité de l'entrée
- Une vraie porte d'entrée pour un diplômé, annoncée d'ordinaire sous un intitulé du genre administrateur de systèmes, administration des ventes ou analyste métier plutôt que sous celui-ci. En pratique, une certification sur la plateforme précise qu'un employeur exploite décide de l'entretien davantage que le nom du diplôme — ce qui coupe des deux côtés : elle est peu coûteuse à obtenir et elle vous attache au produit d'un seul éditeur.
Trouvez un système sur lequel une association, un laboratoire ou un employeur à temps partiel tourne réellement. Listez toutes les actions qu'il exécute aujourd'hui sans personne dans la boucle : affectations, relances, changements de statut, messages envoyés. Marquez chacune comme correcte, à faire relire, ou n'aurait jamais dû être automatique, et portez les trois décomptes à celui qui en est responsable. La discussion que vous récupérez est le métier.
Entrer par le support, qui est une porte et non une destination
analyse au niveau de la tâche →- Ce qui se transfère
- Le guichet est l'endroit où la connaissance du parc applicatif s'acquiert réellement : ce que l'organisation fait tourner, dans quelle version, raccordé à quoi, et ce qui casse un lundi matin. Personne ne remet cette carte à un diplômé. Vous l'assemblez à partir des ennuis des autres, et c'est pourquoi une année ici vaut plus pour cette filière que pour n'importe quelle autre.
- Ce qui manque généralement aux diplômés
- Les diplômés arrivent capables de décrire un processus et incapables de tenir une file où le récit de l'utilisateur est assuré, bien intentionné et faux sur le seul détail qui décide de tout. Ils sous-estiment aussi de quoi l'échelon d'entrée est fait : la moitié répétitive de la file — réinitialisations, déblocages, demandes d'accès, l'imprimante — est la cible d'automatisation la plus nette d'un bureau, parce que le problème est étroit et qu'une machine peut vérifier si la réparation a marché.
- La réalité de l'entrée
- C'est depuis trente ans l'une des portes principales vers les métiers de la technologie, et elle se resserre pour trois raisons distinctes dont une seule est une machine. Le régulateur des infocommunications de Singapour a évalué comme à fort impact les postes autonomes de support applicatif et système, et les a toutes les trois nommées : des outils qui répondent aux questions du support et aiguillent les tickets, la fonction développement et DevOps qui absorbe la maintenance sous Agile et CI/CD, et un fournisseur de SaaS ou de PaaS qui reprend la maintenance et la mise à jour du logiciel. La deuxième est une réorganisation et la troisième une décision d'achat, et aucune des deux n'est affectée par votre niveau dans ce travail. Préparez-vous à une porte qui se resserre pour des raisons qu'aucune compétence technique de votre part ne peut toucher.
Travaillez ou faites une permanence bénévole là où arrivent de vraies demandes : l'informatique du campus, les systèmes d'une association, un emploi à temps partiel. Consignez-en dix et rangez-les en deux tas : celles où une machine peut dire si la réparation a marché, et celles où seule une personne le peut. Ce rapport est ce que l'outillage prend en premier, et vous l'avez produit plutôt que lu.
Où ce travail est parti : plateforme et exploitation
analyse au niveau de la tâche →- Ce qui se transfère
- La moitié opérationnelle de cette filière — penser en termes de ce qui tourne, de ce qui dépend de quoi et de qui sera appelé — appliquée là où c'est tout le métier et non un module. La même étude sur la main-d'œuvre qui attendait un rétrécissement du support autonome attendait que ces attributions atterrissent ici : elle dit que la surveillance du niveau de service et de la performance des systèmes passe aux équipes DevOps, et range les ingénieurs d'automatisation et d'orchestration parmi les profils dont la demande augmente.
- Ce qui manque généralement aux diplômés
- Les diplômés de cette filière ont écrit du paramétrage pour un devoir et n'ont jamais tenu quoi que ce soit au long d'une mauvaise nuit, ce qui est la part qui ne s'étudie pas. Le deuxième manque, c'est la lecture : ce travail est de plus en plus fait de code et de paramétrage que vous n'avez pas écrits, générés ou non, et une large enquête auprès de praticiens a trouvé que l'adoption de ces outils se relie positivement au débit de livraison et négativement à sa stabilité. On livre davantage et davantage casse, donc la valeur se pose chez qui sait dire pourquoi.
- La réalité de l'entrée
- Dans la plupart des endroits, ce n'est pas une porte pour un diplômé. La même étude a nommé l'ingénieur DevOps comme un saut de difficulté faible à moyenne depuis les postes de support, et c'est la route honnête : deux ou trois ans d'abord au guichet ou en développement. En venant de cette filière plutôt que de l'informatique, attendez-vous à être le programmeur le plus faible de la salle et à être payé pour savoir à quoi la chose est raccordée.
Prenez un service que votre université ou une association fait tourner et que vous n'avez pas construit, et découvrez deux choses sans ouvrir la documentation : qui serait appelé s'il s'arrêtait à trois heures du matin, et de quoi il dépend sans que personne l'ait écrit. Le temps que cela vous prend est la mesure, et la réponse que personne ne peut vous donner est le résultat.
Décider ce qu'une organisation achète, allume et met au rebut
analyse au niveau de la tâche →- Ce qui se transfère
- Connaître le parc applicatif, que cette page de métier désigne comme l'entrée qui contraint et celle que personne ne peut aller chercher : quelle étape est réellement le goulet, quel système détient l'enregistrement qui fait foi, à qui les chiffres bougeront s'il change, et qui sera fâché. Cela se récolte par quelqu'un capable d'aller voir et de demander, et cette filière est celle qui vous apprend quoi demander.
- Ce qui manque généralement aux diplômés
- Les diplômés de cette filière savent mener la réunion et ne savent d'ordinaire pas construire la vérification. La tâche qui décide si un outil vaut d'être adopté consiste à sortir de vrais dossiers de l'activité — pas la démonstration de l'éditeur —, à faire tourner l'outil dessus, et à compter combien de fois il a raison, tort, et tort avec assurance. Cela ressemble plus à concevoir une expérience qu'à gérer un projet, et décider ce qui compte comme correct pour cette entreprise-là est un jugement métier déguisé en jugement technique.
- La réalité de l'entrée
- Rarement un premier emploi, et difficile à lire de l'extérieur : cette page de métier marque sa confiance comme faible parce que presque tout ce qui est publié sur ce rôle est écrit par des gens qui vendent des prestations d'adoption. Deux règles nomment désormais une personne et non une équipe : un mémorandum fédéral des États-Unis impose à chaque administration de désigner un responsable en chef de l'IA, et depuis août 2026 un déployeur d'un système à haut risque dans l'UE doit confier la supervision à des personnes physiques disposant de la compétence, de la formation et de l'autorité nécessaires. Lisez-les comme la preuve que le devoir existe, pas comme la preuve que le poste est financé là où vous vivez.
Prenez un outil qu'une association, un service ou votre employeur ont allumé, et construisez la vérification que personne n'a construite : rassemblez vingt vrais dossiers d'avant sa mise en route, faites-le tourner dessus, et comptez trois choses — juste, faux, et faux avec assurance. Vingt dossiers, c'est peu, et cela vous dira quand même quelque chose que la documentation de l'éditeur ne dit pas.
Ce qu'il faut ajouter en dehors des cours#
Il s'agit de ce qui manque couramment aux diplômés en pratique — non d'affirmer que votre école ne l'a pas enseigné.
Du temps passé à l'intérieur d'un parc applicatif que vous n'avez pas monté — un stage dans une direction informatique, un emploi à temps partiel, les systèmes d'une association. Ce que les travaux de cours ne peuvent pas reproduire, c'est l'héritage : un système que vous avez construit le mois dernier est un système que vous comprenez entièrement, et aucun de ceux qu'on vous paiera pour exploiter ne sera ainsi.
Lire la documentation d'un système contre le système qui tourne et trouver où les deux divergent. Ils divergent toujours. Là où ils divergent est là où se trouve le métier, et savoir énoncer cet écart en une phrase est ce qui sépare cette filière de la certification qui vous obtient le même premier entretien.
La partie du droit qui nomme l'exploitant plutôt que le constructeur — dans l'UE, les devoirs que le règlement européen sur l'IA place sur le déployeur, et là où vous êtes, son équivalent local. Toutes les destinations de cette filière sont du côté de l'exploitation, qui est le côté sur lequel ces obligations atterrissent, et elles sont courtes et publiques.
Ce semestre#
Une ou deux actions, chacune produisant quelque chose que vous pouvez montrer à quelqu'un. Pas une liste de lectures.
Choisissez un système que vous pouvez réellement atteindre — celui d'une association, d'un employeur à temps partiel, de votre département — et dessinez ce à quoi il est raccordé en interrogeant les gens plutôt qu'en lisant la documentation. Comptez les raccordements que personne n'a su nommer. Ce décompte est la seule chose de cette page que personne ne peut générer à votre place.
Écrivez la définition d'un champ dont dépendent des décisions : ce qu'il veut dire, qui a le droit de le poser, et quand il est faux. Montrez-la à deux personnes qui s'en servent. Si elles ne sont pas d'accord entre elles, gardez les deux versions — ce désaccord est la pièce, et le produire est le travail.
Questions fréquentes#
Ce site ne répondra pas à cela par une note, et pour cette filière un verdict unique serait particulièrement trompeur, puisque ses parties bougent en sens contraires. Lisez les quatre pages de métier qu'elle atteint — le responsable des systèmes de gestion, le support, plateforme et exploitation, et la personne qui répond de l'adoption de l'IA dans une entreprise — et comparez-les tâche par tâche. Ce qui tient dans les quatre est la même chose : savoir ce qu'une organisation fait déjà tourner, ce qui dépend de quoi, et ce qu'un enregistrement a le droit de signifier. Ce qui est réellement plus mince, c'est le premier échelon, parce que le support se resserre pour trois raisons dont une seule est une machine. La question qui mérite d'être tranchée n'est donc pas de savoir s'il faut quitter cette filière. C'est de savoir si vous pouvez atteindre cette connaissance du parc applicatif sans le poste d'entrée qui vous la remettait autrefois, et les chemins de cette page sont écrits pour être lus comme quatre réponses différentes à cela.
Les deux répondent à des choses différentes. L'informatique vous forme à construire un système assez précisément pour qu'une machine l'exécute. Celle-ci vous forme à faire tourner et à modifier des systèmes construits par d'autres, dans une organisation qui ne s'arrêtera pas de fonctionner pendant que vous le faites. Là où les deux se recouvrent — écrire du code et du paramétrage de routine —, le diplômé d'informatique est mieux entraîné et les outils sont les plus forts, si bien que concourir là est la seule erreur que cette filière rend facile. Concourez là où elle diffère : aucun modèle ne sait lequel de vos quatre systèmes détient le vrai enregistrement client, et les gens qui le savent sont payés pour cela.
Le pont tel qu'on le décrit d'ordinaire — prendre ce qu'un responsable veut et le reformuler pour qu'un ingénieur puisse agir — est très proche de ce qu'un outil de rédaction réussit le mieux, et c'est là le problème honnête de l'argument de vente le plus ancien de cette filière. Ce qui n'est pas devenu moins cher se trouve en dessous : savoir laquelle des étapes décrites les gens sautent en réalité, et dans quel système se trouve la vraie version d'un chiffre. Un banc d'essai construit à partir de journaux de requêtes d'entrepôts de données d'entreprises réelles, et non de jeux de données publics, a trouvé qu'un modèle de langage brut obtenait zéro là où les bancs d'essai publics affichent quatre-vingts à quatre-vingt-dix pour cent, et les raisons étaient structurelles : les schémas réels pourrissent jusqu'à comporter plusieurs colonnes du même nom, et chaque organisation porte son parler local. Traduire tout seul vaut donc moins qu'avant, et traduire fait par quelqu'un qui connaît le parc applicatif vaut plus.
Probablement plus étroite, et la part utile est le pourquoi. Le régulateur des infocommunications de Singapour a évalué comme à fort impact les postes autonomes de support et a nommé trois routes : des outils qui répondent aux questions du support et aiguillent les tickets, la fonction développement et DevOps qui absorbe la maintenance sous Agile et CI/CD, et un fournisseur de SaaS ou de PaaS qui reprend la maintenance et la mise à jour du logiciel. Seule la première est de l'automatisation. Les deux autres sont une réorganisation et une décision d'achat, et aucune n'est affectée par votre niveau dans ce travail. Deux choses rendent cette étude plus utile qu'un titre récent, et non moins. C'est une prévision et non une mesure, publiée en 2022 sur une analyse datée de 2020 — la route qu'elle appelle automatisation a donc été écrite avant que les outils génératifs n'atteignent le public, tandis que les deux routes organisationnelles sont celles que ses auteurs pouvaient déjà voir se produire. Et son horizon est désormais épuisé, ce qui en fait l'une des rares prédictions sur ce métier que vous pouvez réellement trancher. Allez la trancher au guichet auquel vous candidatez : demandez combien de personnes y travaillent aujourd'hui contre il y a trois ans, et si la maintenance des systèmes principaux est encore en interne.
Pour le premier emploi, souvent oui, et cela vaut d'être su plutôt que mal pris : une certification sur la plateforme qu'un employeur exploite vous obtient l'entretien du poste qui administre cette plateforme. Ce qu'elle ne fait pas, c'est voyager. Elle est propre au produit d'un éditeur, elle expire, et l'employeur qui la valorise la valorise parce que vous tiendrez son instance — pas parce que vous savez juger quelle instance vaut d'être tenue. Le jugement que cette filière peut produire n'a aucun certificat derrière lui, et c'est exactement pour cela qu'il doit apparaître comme quelque chose que vous avez fait : un système que vous avez cartographié, une définition que vous avez écrite, un décompte que vous avez produit.
Assez pour lire, et la cible est une chose précise plutôt qu'un niveau. Le travail auquel cette filière mène est plein de code et de paramétrage que vous n'avez pas écrits, générés ou non, et la question pour laquelle on vous paie est de savoir ce que cela touche et ce qui se passe si c'est faux — pas si vous auriez pu le produire plus vite. En pratique cela veut dire du SQL que vous savez lire contre un schéma que vous n'avez jamais vu, un langage de script que vous savez suivre, et l'habitude d'aller voir quelles tables une requête joint avant de répéter ce qu'elle a renvoyé. Essayer de battre à la programmation des gens sortis d'informatique est la version perdante de cette filière, et c'est aussi la version où les outils sont les meilleurs.
Méthode#
Les évaluations portent sur des tâches, non sur des filières. Suivez n'importe quelle direction ci-dessus jusqu'à sa page métier pour voir quelles tâches changent, quelle est la force des preuves, et ce qu'elles ne montrent pas encore.