TP1 : Structures de contrôle et variables en C

1) Parking urbain dynamique (tarifs par paliers, rabais et arrondis)

Contexte : un parking intelligent facture à la minute avec paliers horaires et rabais selon
heure d’arrivée.
Requirements :

 Tarif par minute :

o 0–120 min : 500 FCFA / heure (arrondir au minute près)
o 121–300 min : 400 FCFA / heure pour la portion au-delà de 120 min
o 300 min : forfait unique 2000 FCFA (quel que soit le supplément)
 Rabais : arrivée entre 22:00 et 06:00 → -15% du montant (appliqué après arrondi
final).
 Prendre en compte minutes partielles (ex. 2h10 = 130 min).
 Valider entrée (minutes positive, heure d’arrivée entre 0 et 23)
Contraintes techniques :
 Écrire calcul sans utiliser de flottants (entiers uniquement) ; arrondir toujours à l’unité
la plus proche vers le haut.
Cas tests :
 130 min, arrivée 23 → applique palier + rabais.
 400 min → applique forfait 2000.

2) Notation universitaire avec rattrapage et pondération multiple

Contexte : université avec composantes TP (30%), CC (20%), examen final (50%), et règle
de rattrapage.
Requirements :

 Calculer moyenne pondérée.

Si moyenne ∈ [8, 9.99] et note examen < 12 → proposer rattrapage : lire

 Si moyenne ≥ 10 → admis.

note_rattrapage (remplace uniquement la note examen si meilleure).
 Cas particulier : si l’étudiant a un bonus de présence (>75% présences) : ajouter +0.5
à la moyenne (mais plafonner à 20).
 Écrire deux versions : (A) if imbriqués expressifs, (B) logique avec
early-return/structure claire.
Contraintes :
 Entrées dans [0,20], valider.
Cas tests :
 moyenne initiale 9.2, examen 11, rattrapage 13 → admis.

3) Distributeur multi-produits avec gestion de stock et rendu de monnaie

Contexte : automate qui vend trois produits, gère stock, rend monnaie et affiche erreurs.
Requirements :

 Produits (id 1..3) avec prix, stock initial (configurable).

 L’utilisateur insère un montant (entier). Le programme doit :

1
 o vérifier disponibilité,
o vérifier suffisance,
o vendre (décrémenter stock),
o rendre la monnaie minimalement (billets/ pièces donnés en valeurs
1000,500,100,50,10).
 Gestion d’erreurs : choix invalide, stock nul, montant insuffisant.
 Implémenter switch pour choix produit et une boucle pour rendre la monnaie
(greedy).
Cas tests :
 produit 2 stock 0 → message d’indisponibilité.
 montant exact → pas de rendu.

4) Détection de fraude par règles combinatoires et seuils géographiques

Contexte : système anti-fraude pour transactions internationales.

Requirements :

 Transaction suspecte si :
o montant > 1 000 000 OU
o (montant > 500 000 ET pays ≠ Togo) OU
o plus de 3 transactions du même compte en <60 minutes (simulé : lire
timestamps en secondes).
 Entrées : montant, pays (string), tableau d’timestamps des transactions récentes.
 Implémenter logique booléenne compacte et reporter toutes les règles qui déclenchent
(afficher lesquelles).
Contraintes :
 Pas de bibliothèques externes ; manipuler chaînes avec strcmp.
Cas tests :
 montant 600k, pays « Ghana » → suspect rule 2.
 plusieurs transactions à timestamps proches → suspect rule 3.

5) Simulation de caisse avec clôture conditionnelle et annulations

Contexte : caisse d’un magasin capable d’enregistrer articles, annuler la dernière, et clôturer
quand seuil atteint.
Requirements :

 Lire montants successifs ; commandes possibles : ajout X, annule, cloture.

 Clôture automatique si total ≥ 100000 ou si commande cloture.
 annule supprime le dernier élément (stack behaviour). Si plus d’une annulation
consécutive et pas d’articles → message d’erreur.
 À la clôture afficher : total, nombre d’articles, plus grand article, moyenne.
Contraintes :
 Utiliser un tableau dynamique simulé (taille max 1000) et indices ; gérer
dépassement.
Cas tests :
 séries d’ajout/annule ; fermer au seuil.

2
6) Authentification robuste avec verrouillage progressif

Contexte : portail qui impose délais croissants après échecs.

Requirements :

 Mot de passe connu (ex : "Admin!2026"). L’utilisateur a 3 tentatives rapides. Après 3

échecs, le compte est verrouillé pour T secondes où T = 10 × 2^(k-1) pour le k-ième
bloc de verrouillage (simulateur ; ne dormir réellement pas, mais afficher T).
 Afficher messages distincts : tentative restante, blocage, réinitialisation après succès.
 Gestion des entrées vides et caractères spéciaux.
Contraintes :
 Simuler la logique de blocage sans utiliser sleep (afficher la durée seulement).
Cas tests :
 3 échecs -> block 10s; 3 autres échecs -> block 20s.

7) Production industrielle avec probabilités de défaut et arrêt d’urgence

Contexte : ligne produit pièces ; arrêté si taux défaut dépasse seuil glissant.
Requirements :

 Lire N pièces produites. Pour chaque pièce lire ok ou defaut.

 Calculer pour fenêtre glissante de dernière M pièces ([Link]. M=50) le taux de défaut ;
si > seuil ([Link]. 5%) → lancer procédure arrêt (afficher message et nombre d’items
jusqu’à l’arrêt).
 Permettre commande forcer_continuer (simulate break/continue effect).
Contraintes :
 Implémenter fenêtre glissante en O(1) par itération (compteur, pas recompute full).
Cas tests :
 défauts concentrés → arrêt rapide; forcer_continuer permet continuer malgré tout.

8) Calcul de facture progressive avec paliers et plafonds mensuels (boucles

+ conditions)

Contexte : facturation d’eau où le tarif dépend du pallier de consommation cumulée par jour.
Requirements :

 Lire consommation quotidienne sur 30 jours. Barème par jour cumulatif : 0–

10m³@100, 11–30@150, >30@300 (ces paliers s’appliquent sur la consommation
mensuelle cumulée, chaque jour on ajoute).
 Appliquer un plafond mensuel de 200 000 FCFA ; si dépassé, afficher message et
arrêter lecture restante (utiliser break).
 À la fin afficher distribution par pallier (combien de m³ dans chaque palier).
Contraintes :
 Gérer saisie partielle et valeurs négatives (rejeter).
Cas tests :
 journées avec forte consommation → arrêt au plafond.

9) Détection et énumération de nombres parfaits et amicaux dans un

intervalle
3
Contexte : outil d’analyse mathématique pour entiers sur intervalle L..R.
Requirements :

 Lire L et R (1 ≤ L ≤ R ≤ 1 000 000).

 Trouver tous les nombres parfaits dans cet intervalle.
 En bonus : détecter paires amicables (a,b) où sommeDiv(a)=b et sommeDiv(b)=a (et
a≠b), en évitant double-report.
 Optimiser calcul des diviseurs : ne tester que jusqu’à sqrt(n) et accumuler paires.
Contraintes :
 Limiter calcul (si R-L trop grand, proposer découpage en blocs ou avertir).
Cas tests :
 intervalle 1..10000 → doit trouver 6,28,496,8128.

10) Analyse avancée de notes avec détection d’anomalies

Contexte : service qualité d’un examen qui détecte « triche » potentielle.

Requirements :

 Lire N notes (N variable). Calculer : moyenne, écart-type (population), médiane, top

5%.
 Détecter anomalies : notes identiques > 30% du groupe → signaler « possible triche
» ; ou écart-type très faible (< 0.5) avec moyenne > 14 → signal.
 Implémenter tri (vous pouvez utiliser un tri simple O(n log n) implémenté par vous,
ex. quicksort ou mergesort) pour la médiane.
Contraintes :
 Fournir justification algorithmique pour le choix du tri et sa complexité.
Cas tests :
 dataset avec 30% identiques → alerte.

11) Jeu de devinette évolué (bornes dynamiques et score)

Contexte : jeu qui ajuste la difficulté et maintient score utilisateur.

Requirements :

 Ordinateur choisi nombre dans [low, high]. À chaque essai, indiquer « trop grand » / «
trop petit » et réduire l’intervalle possible.
 Si l’utilisateur fait une supposition hors intervalle actuel → avertissement (ne
décrémente pas les tentatives).
 Système de score : score initial 1000 ; pour chaque mauvaise tentative, score -=
taille_intervalle/10 (arrondir). Bonus si trouvé en < log2(range) tentatives.
 Implémenter boucle avec conditions d’arrêt et valide inputs.
Cas tests :
 game with range 1..1000, simulate guesses narrowing.

12) Gestion de stock multi-entrepôts avec politique FIFO/LIFO

Contexte : système simple pour deux entrepôts et transferts.

Requirements :

4
  Deux entrepôts A et B, chaque entrée de stock a quantité et numéro lot (timestamp).
Les sorties suivent politique configurable : FIFO ou LIFO.
 Opérations : reception(entrepot, qty), sortie(entrepot, qty),
transfert(A,B,qty).
 Si sortie demandée > stock total → partielle possible et afficher message.
 Implémenter logique de sélection de lots correcte selon FIFO/LIFO (simuler via
tableaux de structs).
Contraintes :
 Struct Lot {int qty; int id;} ; manipuler tableaux avec indices.
Cas tests :
 réception 100 lot1, réception 50 lot2, sortie 120 en FIFO → consommer lot1 puis lot2.

13) Simulation d’un prêt amortissable (boucle et conditions d’arrêt)

Contexte : calcul d’un prêt remboursé par mensualités variables selon versement additionnel.
Requirements :

 Lire capital, taux annuel (en pourcentage), mensualité fixe minimale, et tableau de
versements additionnels ponctuels (mois, montant).
 Calculer mois par mois : intérêts sur restant, appliquer versement (mensualité +
éventuelle addition), stopper quand restant ≤ 0.
 Si mensualité < intérêts mensuels → afficher « amortissement impossible ».
 Afficher nombre de mois, total intérêt payé, et tableau résumé (pour premier 12 mois).
Contraintes :
 Faire arrondis aux unités ; gérer taux 0.
Cas tests :
 capital 1 000 000, taux 12% annuel, mensualité 10 000 → voir impossibilité ou long
terme.

14) Détection de nombres premiers optimisée (crible partiel et tests)

Contexte : génération de la liste des premiers dans un intervalle large.

Requirements :

 Implémenter version 1 : test simple par divisions jusqu’à sqrt(n).

 Version 2 (optimisation) : utiliser crible d’Ératosthène segmenté pour intervalle L..R
(R jusqu’à 10^7).
 Comparer temps (mesurer itérations) et expliquer choix de boucle/contrôle pour
performance.
Contraintes :
 Mémoire limitée à une taille fixe (expliquer bornes).
Cas tests :
 L=1, R=1e6 → vérifier correctness.

15) Statistiques de ventes avec détection de jours exceptionnels (boucle et

logique booléenne)

Contexte : analyser dataset quotidien de ventes pour extraire tendances.

Requirements :

5
  Lire ventes journalières pour N jours. Calculer : moyenne mobile sur 7 jours,
détection « jour exceptionnel » si vente > moyenne_mobile*1.5 et > 2×écart-type
local.
 Lister segments de croissance continue (>5 jours) et afficher meilleur segment (début,
fin, somme ventes).
 Implémenter contrôle de flux pour sauter jours manquants (continue) et arrêt si trop
de données manquantes (break).
Cas tests :
 datasets contenant trous (jours sans données).

16) Conversion et validation multi-base (switch et boucles)

Contexte : outil qui convertit des entiers signés entre bases (2,8,10,16) avec validation.
Requirements :

 Lire nombre en base X (X fourni), valider la chaîne (caractères autorisés), convertir

en entier signé (32-bit), puis afficher représentation en bases cibles.
 Gérer overflow détecté (valeur trop grande pour 32-bit) et signaler.
 Utiliser switch pour branches base et boucle pour parsing digits.
Contraintes :
 Pas d’utilisation de strtol ; écrire parsing à la main.
Cas tests :
 entrée « 0x7FFFFFFF » base16 → OK ; « 0xFFFFFFFF » → overflow pour signed.

17) Compression simple par run-length encoding (RLE) avec exceptions

Contexte : compresseur RLE pour séquences de caractères ; prévoir échappement si

séquence > 255.
Requirements :

 Lire une chaîne (peut contenir caractères non imprimables) ; produire RLE minimal
où chaque paire est (count, char) ; si count>255, émettre plusieurs paires.
 Gérer cas où char spécial d’échappement doit être encodé (choisir \), éviter
ambiguïté.
 Implémenter avec boucles et conditions ; tester sur gros strings ( > 100k caractères
simulated).
Contraintes :
 Allouer mémoire de sortie en conséquence ; gérer dépassement.
Cas tests :
 input AAAA...A (500 fois) → deux paires (255,A)+(245,A).

18) Analyse de logs séquentiels — regroupement et seuils (pattern

break/continue)

Contexte : analyser un flux de logs (niveau INFO/WARN/ERROR) pour regrouper

séquences d’erreurs.
Requirements :

 Lire lignes contenant timestamp niveau message.

6
  Regrouper séquences contiguës d’ERROR ; si séquence > K (ex. K=5) et durée < T
(ex. T=600s) → alerter.
 Ignorer (continue) les lignes vides/commentées ; si fichier corrompu (format invalide)
→ afficher erreur et break.
 Afficher pour chaque alerte : début, fin, count, durée.
Cas tests :
 logs avec 6 ERROR en 300s → alerte.

19) Algorithme de scheduling simplifié (boucle + conditions multiples)

Contexte : scheduler single-core qui planifie jobs avec priorité et quantum (round-robin avec
priorité).
Requirements :

 Jobs : id, durée restante, priorité (1..5). Le scheduler exécute par priorité
décroissante ; au sein d’une même priorité, round-robin avec quantum Q.
 Implémenter boucle principale simulant ticks ; permettre arrivée dynamique de jobs
(lecture d’un tableau d’événements).
 Gérer starvation : si un job attend > W ticks → priorité +=1 (max 5).
 À la fin afficher ordre d’exécution (timeline), temps de réponse moyen.
Contraintes :
 Implémenter files par priorité (tableaux circulaires), éviter copies lourdes.
Cas tests :
 scenario mixte montrant montée en priorité pour éviter starvation.

20) Validation d’un tableau Sudoku partiel (contrôles imbriqués et early-

exit)

Contexte : vérificateur pour grilles 9×9 partiellement remplies.

Requirements :

 Lire 9×9 (0 pour vide). Vérifier :

o aucune ligne ne contient doublon non-zero,
o aucune colonne,
o aucun sous-carré 3×3.
 En cas d’erreur, afficher position et raison et return immédiatement (early-exit).
Sinon afficher « valide ».
 Implémenter avec boucles imbriquées optimisées et tableaux d’occurrence (bool
visited[10]).
Contraintes :
 Complexité O(81) ; expliquer pourquoi.
Cas tests :
 grille avec doublon ligne 5 → arrêter à découverte.