Quiz 5 — Expert & carrière

require_login dit « connecté et accès au cours/activité » ; require_capability dit « autorisé (droit) dans ce contexte ». Les deux sont nécessaires.

s() = texte simple échappé ; format_string() = noms/titres (échappe + filtres) ; format_text() = contenu riche HTML (nettoie + filtres + fichiers). On échappe à la sortie.

Via le DML paramétré (get_record($t, ['id'=>$id])) ou get_records_sql($sql, $params) avec des placeholders. Jamais de concaténation dans une requête.

À appliquer un type PARAM_* à une valeur déjà en main (issue d’un calcul, d’un WS). Complète required_param. On type toute donnée douteuse.

Non, si le plugin stocke des données perso : le Privacy API (metadata + export + suppression) est obligatoire pour la conformité RGPD et la publication.

Le coding style (PHP_CodeSniffer) : indentation, nommage, PHPDoc, en-tête GPL, fonctions interdites, patterns de sécurité. Vise zéro erreur avant publication.

Avec PHPUnit (framework intégré : advanced_testcase, générateurs de données, resetAfterTest). Filet contre les régressions.

À tester les parcours utilisateur dans un navigateur (scénarios Gherkin Given/When/Then). Vérifie l’UX de bout en bout.

Parce qu’un mod qui ne se sauvegarde pas correctement perd les données des utilisateurs à la restauration. C’est la partie la plus négligée et la plus testée en review.

Le cache (MUC — Moodle Universal Cache) pour éviter de recalculer, plus des requêtes DML efficaces et un cron correct. Query-profiling pour repérer les requêtes lourdes.

Nettoyage, envois, calculs, sauvegardes… Elles supposent un cron système qui appelle admin/cli/cron.php régulièrement. Sans cron, « rien ne se passe » en arrière-plan.

Sécurité, coding style, i18n, privacy, backup/restore, absence de core hack, licence GPL. Publier = passer cette revue (Partie 11).

Peu de devs maîtrisent à la fois le cœur PHP de Moodle et le web moderne (React, headless, LTI). Ce pont (web services + outil LTI Next.js) se facture cher.

TJM : il protège ton temps pendant la montée en maîtrise. Le forfait vient plus tard, quand tu sais estimer un type de mission sans risque.

La mission est consommable (temps = revenu, puis fini) ; le produit est un actif qui s’additionne à chaque client (MRR). Le produit découple revenu et temps.

Un micro-SaaS : outil LTI multi-tenant + abonnement par établissement/quotas. Standard LTI = portabilité (tout LMS), donc revenu récurrent (Partie 13).

Non : elle porte sur la licence du code, pas sur le revenu. On vend le service (SaaS hébergé, support, développement) — d’où l’intérêt du SaaS/LTI (valeur sur ton infra).

Généralement oui, sous conditions (clause d’exclusivité/loyauté, secteur non concurrent, hors temps de travail). À vérifier au cas par cas — ce n’est pas un conseil juridique.

Ils ouvrent Moodle à des fronts modernes (Next.js), apps mobiles, systèmes tiers. Brancher Moodle sur du moderne est une compétence recherchée et bien payée.

Vérifier l’accès (require_login + require_capability), assainir l’entrée (PARAM_*), échapper la sortie (s/format_*), protéger les actions (sesskey). Non négociable.