Le socle : penser comme l'informatique de gestion
Avant les outils, les concepts. Cette page installe le vocabulaire de base et les modèles mentaux qui rendent tout le reste évident.
L'informatique de gestion, c'est résoudre des problèmes d'affaires avec des plateformes existantes, pas écrire du code. Tu vas surtout manipuler de la donnée : la nettoyer (ETL), la modéliser (relations), la mesurer (KPI). Deux mondes cohabitent : l'IT (bureau) et l'OT (usine). Et la philosophie de tes outils, c'est le low-code : configurer plutôt que coder.
Informatique de gestion ≠ développement logiciel
Tu viens du développement « produit » : tu construis des applications à partir de code. En informatique de gestion, l'objectif n'est pas le logiciel, c'est le résultat d'affaires. La question n'est jamais « quelle architecture ? » mais « quel problème du département production veut-on régler, et quel outil le règle le plus vite ? »
| Développement logiciel (ce que tu connais) | Informatique de gestion (le stage) | |
|---|---|---|
| But | Livrer un produit/feature | Régler un problème opérationnel |
| Moyen | Écrire du code (React, SQL…) | Configurer des plateformes (Power Platform…) |
| Mesure de succès | Code qui marche, tests verts | Décision plus rapide, paperasse éliminée, KPI suivi |
| Interlocuteur | Product, autres devs | Opérateurs, maintenance, gestionnaires |
| Cycle | Sprints, déploiements | Petites itérations rapides, très proches du terrain |
C'est la différence entre écrire une librairie et scripter une intégration. Quand tu branches Stripe + un webhook + un courriel de confirmation sans réécrire chaque morceau, tu fais déjà de « l'informatique de gestion » dans l'esprit. Ton avantage : tu sais déjà raisonner en termes de données, d'événements et d'automatisation.
IT vs OT : les deux mondes d'une usine
C'est la distinction qui structure une usine. La comprendre te fera paraître crédible immédiatement.
| IT — Information Technology | OT — Operational Technology | |
|---|---|---|
| Gère | L'information de bureau | Les machines de production |
| Exemples | Courriels, fichiers, Power BI, SharePoint | Automates (PLC), capteurs, SCADA, robots |
| Priorité n°1 | Confidentialité des données | Disponibilité : la ligne ne doit jamais s'arrêter |
| Rythme | Mises à jour fréquentes | Très stable, on touche le moins possible |
| Outils du stage | Power Platform, SharePoint | Ignition, PI |
Ton stage vit à la frontière : tu prends des données nées en OT (capteurs, production) et tu les rends utiles en IT (tableaux de bord, automatisations, rapports).
En OT, on ne « déploie pas en prod le vendredi soir ». Une erreur peut arrêter une machine qui produit 24 h/24 — ça coûte très cher. La culture est prudente : on teste, on valide, on demande avant de toucher à un système connecté à la production. Garde ce réflexe.
- PLC (automate programmable) : le petit ordinateur industriel qui contrôle une machine.
- SCADA : système qui supervise et contrôle les procédés à distance (ici, Ignition).
- HMI : l'écran tactile devant la machine (Human-Machine Interface).
- Historian : base de données spécialisée qui archive les mesures dans le temps (ici, PI).
- Tag : un point de mesure nommé (ex.
Machine3.Temperature).
Les données : relationnel vs séries temporelles
Tu connais bien les bases relationnelles (Postgres/Supabase). En usine, un deuxième type de données domine : la série temporelle (time-series), c'est-à-dire « telle mesure, à telle seconde, valait telle valeur », répété des millions de fois.
| Relationnel (Postgres/Dataverse/SharePoint) | Série temporelle (PI, historian) | |
|---|---|---|
| Question type | « Quels équipements sont en alerte ? » | « Quelle était la température entre 2 h et 3 h ? » |
| Forme | Lignes & colonnes, relations | (tag, horodatage, valeur) en continu |
| Écritures | Création/mise à jour/suppression | Surtout des insertions (append-only) |
| Analogie | Tes tables Supabase | Un journal de logs horodatés, énorme |
Un historian (PI), c'est une base append-only ultra-optimisée
pour le temps — pense à une table events avec un index sur timestamp,
mais conçue pour avaler des millions de points/seconde et les compresser. Tu n'y fais pas de
UPDATE, tu y ajoutes et tu interroges des plages de temps.
ETL : le mot magique
ETL = Extract, Transform, Load : extraire des données d'une source, les transformer (nettoyer, reformater, joindre), les charger dans la destination. C'est 80 % du travail réel en BI. Dans la Power Platform, l'outil d'ETL s'appelle Power Query.
ETL = un pipeline de données. Chaque étape est comme un maillon de
data.filter().map().groupBy() : tu pars d'un brut moche (un Excel mal formaté,
un export), tu enchaînes des transformations, tu obtiens un jeu propre. Power Query
enregistre ces étapes et les rejoue à chaque rafraîchissement — comme une fonction pure
réexécutée sur de nouvelles données.
KPI : mesurer ce qui compte
Un KPI (Key Performance Indicator) est une mesure qui résume la santé d'un processus : taux de conformité d'une route d'inspection, temps d'arrêt d'une machine, rendement. Tout l'OpEx et tout Power BI tournent autour de « quels KPI suit-on, et est-ce qu'ils s'améliorent ? ». Un KPI industriel classique : l'OEE (rendement global, Overall Equipment Effectiveness).
Le paradigme low-code (et ses limites)
Tes outils principaux sont low-code / no-code : tu construis surtout en configurant (glisser-déposer, propriétés, formules) plutôt qu'en écrivant du code. Ça paraît limité quand on vient du « vrai » dev, mais c'est exactement le but : livrer vite des solutions d'affaires que des non-développeurs peuvent maintenir.
| Avantages du low-code | Limites à connaître |
|---|---|
| Très rapide à livrer | Moins flexible que du vrai code |
| Maintenable par des non-devs | Logique cachée dans des clics → dur à versionner |
| Intégré à tout l'écosystème Microsoft | On reste dans le « bac à sable » Microsoft |
| Gouvernance et sécurité fournies | Quotas, licences, limites de performance |
Le low-code, c'est Zapier/Make + un constructeur d'UI + une base managée, le tout cousu ensemble par Microsoft. Ton réflexe de dev sera un atout énorme : tu comprends déjà les conditions, les boucles, les variables, le JSON, les API. Tu apprends juste où cliquer pour exprimer ce que tu sais déjà penser.
La Power Platform en un coup d'œil
Les trois outils « Power » de l'offre forment une même famille, posée sur une base de données commune (Dataverse) et reliée au reste par des connecteurs.
Power BI
Analyser et visualiser la donnée. Les tableaux de bord.
Power Automate
Déclencheur → actions. La plomberie invisible.
Power Apps
Des applis de saisie, sans coder.
- Dataverse : la base de données « officielle » de la Power Platform (tables, relations, sécurité). C'est le Supabase/Postgres managé de Microsoft.
- Connecteur : un pont préfabriqué vers un service (SharePoint, Outlook, SQL, PI…). Comme un SDK ou un client d'API déjà branché.
- Microsoft 365 (M365) : la suite bureautique (Outlook, Teams, Excel, SharePoint) où vit tout ça.
- Environnement : un espace cloisonné (dev, test, prod) pour tes solutions. Comme des branches/déploiements séparés.
Tu vas constamment faire circuler la donnée entre ces briques : une Power App (saisie d'inspection) écrit dans SharePoint/Dataverse, un flux Power Automate réagit, et Power BI affiche le résultat — pendant qu'Ignition/PI fournit les mesures machines. Ce guide te fait visiter chaque brique dans cet ordre.
Microsoft Learn — parcours d'introduction à la Power Platform : « Découvrir les capacités de Microsoft Power Platform » sur learn.microsoft.com/training/powerplatform. Survol de 1–2 h, idéal pour ancrer le vocabulaire ci-dessus.