Compétence 02 / 06 — BUT Informatique

Optimiser des
applications informatiques

Proposer des applications informatiques optimisées en fonction de critères spécifiques : temps d'exécution, précision, consommation de ressources. Composantes essentielles : formaliser des situations complexes, identifier les algorithmes et structures adaptés, justifier les choix, valider les résultats.

Voir les preuves
2026
Vue d'ensemble

4 preuves,
du formel
au pratique.

Cette compétence couvre deux angles : la rigueur mathématique (optimisation linéaire, théorie des automates) et l'optimisation concrète d'applications réelles (performance web, contraintes de taille et de fluidité en 3D). Les quatre preuves démontrent la capacité à mesurer, modéliser et améliorer des systèmes selon des critères définis.

Méthodes d'Optimisation Automates et Langages App Vote — Performance WebGL — Contraintes de taille
Preuves d'acquisition
Preuve 01 / 04 — R4.04, Mathématiques

Méthodes d'Optimisation — Algorithme du Simplexe

Application de la programmation linéaire et du simplexe à deux problèmes d'optimisation : résolution standard (8 pivots, Z optimal = 10 000) et analyse du cyclage selon la règle de pivot.

Programmation linéaire Simplexe Dégénérescence

Contexte et ressources mobilisées

R4.04, Sujet 2 — résoudre deux problèmes de programmation linéaire par la méthode du simplexe en forme tabulaire, puis analyser le comportement face à la dégénérescence. Cours mobilisés : variables d'écart, critère d'entrée de variable, calcul du rapport de pivot, règles de Bland et Dantzig.

Activités et implication

  • Exercice 1 : 3 variables, 3 contraintes — 8 itérations de pivot jusqu'à Z = 10 000 optimal à (x₁=1, x₂=100, x₃=10 000)
  • Exercice 2 : démonstration du cyclage avec règle D₁ (boucle infinie) vs. règle D₁' (terminaison garantie en nombre fini d'étapes)
  • Interprétation géométrique 3D : identification des sommets du polytope correspondant aux solutions de base

Apprentissages clés

  • Le choix de la règle de pivot est déterminant : une mauvaise règle peut rendre l'algorithme non-convergent
  • Lecture du tableau final : variables hors-base nulles, contraintes actives, valeur de Z — solution lisible directement
  • Lien entre algèbre (tableau du simplexe) et géométrie (déplacement sur les sommets d'un polytope convexe)

Traces sélectionnées

Polytope 3D — région admissible exercice 1 Polytope de la région admissible (Ex. 1)

Représentation 3D du polytope convexe avec les sommets A–E identifiés — visualisation géométrique de l'espace des solutions admissibles.

Polytope 3D — région admissible exercice 2 Polytope de la région admissible (Ex. 2)

Représentation 3D de la région admissible du second problème — les faces colorées correspondent aux contraintes actives.

Rapport Méthodes Opti (PDF) Retour en haut
Preuve 02 / 04 — SAE Automates et Langages

Automates Finis Déterministes et Langages Réguliers

Construction et minimisation d'AFD paramétrés par (b, n, k), preuve de minimalité par la méthode de Nerode, dérivation d'expressions régulières.

Théorie des automates Méthode de Nerode Expressions régulières

Contexte et ressources mobilisées

SAE Automates — construire des AFD reconnaissant des langages définis par δ(r,c) = (b·r + c) mod n, minimiser ces automates par la méthode de Nerode et dériver les expressions régulières correspondantes.

Activités et implication

  • Scénario 1 (b=4, n=2, k=0) : 2 états, automate déjà minimal, expression dérivée : Di = ({0,2}*{1,3})*{0,2}*
  • Scénario 2 (b=5, n=4, k=1) : 4 états, 20 entrées dans la table de transitions, 4 classes de Nerode confirmant la minimalité
  • Représentation graphique des deux automates + vérification par test de mots acceptés/refusés

Apprentissages clés

  • Passage d'une définition abstraite (AFD, relation de Nerode) à une construction concrète et vérifiable
  • Minimiser un automate = fusionner les états indiscernables — raisonnement applicable à d'autres contextes (simplification de circuits, regroupement de cas)
  • Validation formelle de la minimalité, pas seulement intuitive

Traces sélectionnées

Méthode de Nérode — classes et table de transition minimale Minimisation par Nérode (Scénario 1)

Table de partitionnement des classes d'équivalence (D₀, D₁) et table de transition de l'automate minimal à 2 états obtenu.

Expressions régulières et graphes AFD

Représentations graphiques des automates des deux scénarios et expressions régulières dérivées — rapport Automates (PDF).

Rapport Automates (PDF) Retour en haut
Preuve 03 / 04 — SAE S4 (volet performance)

Application de vote — Optimisation des performances

Optimisation mesurable d'une application PHP héritée : cache applicatif, élimination des requêtes N+1, indexation SQL, minification. Résultats : LCP −33%, CLS −100%, requêtes SQL −100% sur pages en cache.

Cache PHP SQL JOIN Index SQL Lighthouse

Contexte et ressources mobilisées

SAE S4 — grille de 8 points de performance à atteindre sur l'application héritée. Approche : mesurer avec Lighthouse et le profiler PHP, identifier les goulots, corriger, re-mesurer. Chaque optimisation est documentée avec métriques avant/après.

Activités et implication

  • Cache applicatif PHP (TTL 5 min) : 0 requête SQL émise sur les pages chaudes (−100%)
  • Élimination N+1 : remplacement des boucles avec requêtes imbriquées par des JOIN — de 4-6 requêtes/page à 1
  • Index SQL sur colonnes filtrées (catégorie, statut) : passage de full scan à index seek (EXPLAIN)
  • Pagination server-side (12/10 items/page), minification des assets (−30%), correction CLS par ajout de dimensions explicites sur les images

Apprentissages clés

  • Mesurer avant d'optimiser : EXPLAIN et Lighthouse permettent de prioriser par impact réel, pas par intuition
  • Hiérarchie des gains : N+1 > indexation > cache > minification — choisir le bon levier en premier
  • Performance perçue (CLS, fluidité) ≠ performance technique (temps serveur) — les deux nécessitent des approches différentes

Traces sélectionnées

Métriques Lighthouse

LCP 1.8s → 1.2s (−33%), CLS 0.228 → 0.000 (−100%) — résultats mesurés avant et après chaque optimisation.

Plans d'exécution SQL (EXPLAIN)

type=ALL rows=1500 (full scan) → type=ref rows=12 (index seek) après CREATE INDEX — gain documenté dans le rapport SAE S4.

Rapport SAE S4 (PDF) Retour en haut
Preuve 04 / 04 — R4-13, 2025-2026

WebGL — Optimisation sous contrainte de taille et de fluidité

Réalisation d'une scène 3D Three.js avec une double contrainte : poids total du projet inférieur à 2 Mo et rendu fluide et réactif pour l'utilisateur (framerate stable, interactions temps réel). Ces exigences ont imposé des choix d'optimisation dès la conception.

Three.js Textures procédurales Géométries paramétriques Post-processing

Contexte et ressources mobilisées

Module R4-13 — scène 3D médiévale avec deux contraintes simultanées : taille totale ≤ 2 Mo (images, code, assets) et expérience fluide (pas de lag visible lors des interactions caméra et des effets temps réel). Documentation Three.js, HTML5 Canvas API pour la génération procédurale, EffectComposer pour le post-processing.

Activités et implication

  • Contrainte taille : toutes les textures générées par code (Canvas 2D) — aucun fichier image importé, sauf le modèle OBJ du casque (géométrie complexe impossible à recréer paramétriquement)
  • Géométries paramétriques : LatheGeometry (verre), ExtrudeGeometry (épée), BoxGeometry (table, murs) — moins coûteuses en mémoire qu'un maillage importé
  • Fluidité : matériaux et géométries partagés entre objets similaires, chaîne de post-processing limitée aux effets essentiels (vignetage, tone mapping ACES)
  • Interactions réactives : caméra orbitale fluide, panneau lil-gui sans impact visible sur le framerate

Apprentissages clés

  • Optimiser dès la conception : la limite de 2 Mo a orienté chaque choix technique (procédural vs. import, partage de matériaux)
  • Comprendre les compromis : une texture procédurale est moins lourde mais plus longue à générer — choix selon le type d'objet
  • Fluidité 3D = gestion des ressources GPU : géométries et matériaux partagés, draw calls minimisés

Traces sélectionnées

Scène WebGL rendue — contrainte 2 Mo respectée Rendu final — contrainte 2 Mo respectée

Scène complète avec textures procédurales, effets et modèle OBJ — entièrement sous la limite de 2 Mo.

Diagramme des textures procédurales Textures générées par Canvas

Cartographie des textures créées par code (pierre, bois, flamme, parchemin) — aucun fichier image externe pour les surfaces majeures.

Ouvrir le projet WebGL Retour en haut
← C1 — Réaliser C2 / 06 C3 — Administrer →