Algorithmique : penser les traitements avant les langages
Avant même d’écrire une ligne de code, dans un réflexe presque automatique, nous commençons à organiser, à décider. Derrière chaque interaction, chaque formulaire, chaque affichage, il existe une logique discrète qui guide ce que l’on va traduire en code. Cette logique n’appartient à aucun langage. Cette manière d’aborder le développement, centrée sur la logique plutôt que sur les outils, prolonge directement la réflexion menée dans « Apprendre à raisonner plutôt qu’apprendre des outils ». Elle se construit en amont, souvent sans que nous la nommions. Pourtant, c’est elle qui conditionne la clarté d’un traitement, sa fiabilité, sa capacité à évoluer.
Nous allons partir d’une situation concrète, la dérouler, la simplifier, puis progressivement la structurer. L’objectif n’est pas d’apprendre à coder différemment, mais de comprendre ce que nous faisons réellement lorsque nous écrivons du code.
Poser la logique algorithmique
Dès que l’on commence à penser une logique applicative, que ce soit en JavaScript dans les interactions, en PHP côté traitement, ou plus loin dans la relation avec une base de données, une même exigence apparaît. Il ne s’agit plus seulement d’afficher ou de styliser, mais d’organiser des actions, de prévoir des enchaînements, d’anticiper des cas.
C’est cette étape, souvent implicite, que nous allons maintenant faire apparaître, en la suivant pas à pas, à partir d’une situation simple, volontairement détachée de l’informatique. Quand nous cherchons à faire fonctionner quelque chose, organiser une action, traiter un formulaire, afficher un résultat, nous décrivons en réalité une suite d’actions. L’algorithmique, c’est cette mise en ordre du réel, une manière de dire quoi faire, dans quel ordre, et dans quelles conditions. Elle ne dépend d’aucun langage. Elle se joue avant JavaScript, avant PHP, comme un plan que l’on esquisse avant de construire. Nous écrivons d’abord une logique, puis seulement avec une syntaxe.
Dans la pratique, elle est partout. Quand on pose une idée sur papier, qu’on esquisse un parcours, qu’on imagine comment une action va se dérouler, on est déjà en train d’organiser une logique. C’est exactement ce que nous explorons dans « Dessiner avant de coder : méthode analogique pour penser une application », où l’on part du terrain pour structurer une idée avant même d’écrire une ligne de code. Dans le développement web, cette logique devient un socle discret qui relie les intentions aux comportements.
Nous allons avancer pas à pas, en commençant par poser un scénario, un objectif à atteindre. On pourra alors commencer à le formuler en langage naturel, par bribes, par séquences. En posant ces étapes, quelque chose va progressivement se clarifier. Des écueils vont apparaitre, des zones d’ombre, des manques, des points de friction ou de blocage. Petit à petit, nous passerons alors à une forme plus visuelle, afin de mettre à plat cette logique et de faire apparaître plus clairement ce qui pourra alors être transposé en code.
Faire apparaître la logique à partir d’une situation simple
Plutôt que de partir d’une définition, prenons une situation simple. Un sac de billes, de couleurs mélangées. Des contenants sont disponibles, plus un sac de rebut. La consigne est précise : trier certaines couleurs en les plaçant dans le réceptacle qui leur est associé, et déposer les autres au rebut. Concrètement, on prend une bille, on lit sa couleur, on décide : soit elle correspond et on la place dans le bon contenant, soit elle part au rebut. On répète jusqu’à épuisement du sac.
Dès ce moment, une logique se met en place. Dans quel ordre traiter les billes ? comment décider ? que faire des cas non prévus ? Ce sont ces choix qui vont structurer le processus. On hésite un instant. Est-ce qu’on prend une bille au hasard, ou une à la fois ? Est-ce qu’on fixe d’abord les couleurs à conserver ? Est-ce qu’on vide le sac, ou qu’on traite au fil de l’eau ? Sans s’en rendre compte, on pose déjà un ordre et des règles.
C’est exactement là que l’algorithmique apparaît. Pas dans une définition, mais dans ce moment où l’on doit organiser une action simple pour qu’elle fonctionne, du début à la fin, sans se perdre. Nous allons garder cette scène sous les yeux et la dérouler pas à pas. Pas de code, pas de syntaxe. Juste des décisions concrètes. L’objectif est de voir apparaître la logique, étape après étape, avant même de chercher à l’écrire.
# poser un point de départ, organiser le traitement et anticiper la fin
# définir des règles de décision claires
# gérer les cas attendus comme les imprévus
# garder un enchaînement lisible et maîtriséCes questions se regroupent autour de quelques points clés : par quoi commencer, comment décider, et à quel moment s’arrêter. Ces repères suffisent à structurer la réflexion sans alourdir la mise en place de l’algorithme. Elles restent en arrière-plan, comme une grille de lecture, implicite.
Décomposer les étapes avant d’écrire le code
Nous posons les étapes en langage naturel. Une suite d’actions ordonnées, compréhensibles sans technique. C’est ici que s’affine l’algorithme. Par exemple : Quelles couleurs souhaitons-nous trier ? Puis, prendre une bille, observer sa couleur, la comparer aux couleurs attendues, décider où la placer, et recommencer. On voit apparaître des actions (prendre, placer), des tests (la bille est-elle de telle couleur), et des comparaisons (mettre en regard la couleur observée avec celles attendues). Cette répétition constitue une boucle : tant qu’il reste des billes, on refait la même suite d’actions.
# définir les couleurs à trier
# prendre une bille
# de quelle couleur est-elle ?
# fait-elle partie des couleurs à trier ?
# définir l'action à mener
# ...C’est souvent à ce stade que des erreurs peuvent apparaitre, par exemple essayer de reprendre une bille sans vérifier s’il en reste. On entrerait alors dans une boucle sans fin. Cette simple vérification introduit déjà une condition essentielle.
# avant de prendre une bille, vérifier s'il en reste au moins une À chaque étape, le système se trouve dans un état précis. Une bille peut déjà être en cours de traitement, classée dans un sac, ou placée en rebut. L’algorithme ne fait pas qu’enchaîner des actions, il fait évoluer ces états au fil des décisions. Cette manière de voir permet de mieux comprendre ce qui se passe réellement, et prépare naturellement à des situations plus complexes, comme la gestion d’un formulaire ou d’une interface interactive.
Un algorithme ne décrit pas seulement ce qui doit fonctionner, mais fait aussi ressortir ce qui peut échouer. Dans notre cas, plusieurs situations doivent être anticipées : une liste de couleurs à trier qui soit vide, une bille dont la couleur n’est pas reconnue, ou une qui possède une valeur inattendue. Prendre en compte ces cas limites évite les comportements incohérents et renforce la robustesse du processus, dès sa conception.
# s'assurer qu'une liste de couleurs à trier soit définie
# que faire si la bille n'a pas de couleur
# que faire si une bille possède une couleur non listée
# ...À partir de là, trois repères apparaissent et prennent une vraie place dans le raisonnement. D’abord, la séquence qui impose un ordre logique aux actions et évite d’agir au hasard. Ensuite, les conditions qui introduisent et imposent des choix nous obligeant ainsi à anticiper plusieurs chemins possibles. Et enfin, les répétitions qui permettent de traiter une portion de chemin sans avoir à réécrire la même logique à chaque fois. À ce niveau, on peut commencer à esquisser une représentation visuelle très simple du cheminement, sans basculer dans un formalisme complet. Sans entrer dans UML, on esquisse simplement une représentation visuelle, pour voir comment une logique peut être posée et suivie :
- une étape devient un bloc, identifiable, qui représente un moment du traitement, pouvant correspondre à une action ou à un état
- une question devient une bifurcation, avec divers chemins distincts selon la réponse obtenue
- une flèche indique le sens du parcours, elle montre vers quelle étape se diriger ensuite, et peut aussi signaler un retour vers une étape précédente lorsque le processus se répète
UML, Unified Modeling Language
UML est un langage de modélisation visuelle qui permet de représenter un système, ses composants et leurs interactions à l’aide de diagrammes standardisés. Il sert à rendre une logique lisible, partageable et vérifiable avant même d’écrire du code.
Dans cet article, nous n’avons pas pour objectif d’initier à UML en tant que langage formel. Nous en retenons simplement l’idée centrale : dessiner une logique pour mieux la comprendre et la suivre.
Variante : des sacs pourraient être imbriqués
On peut déjà évoquer, sans entrer dans des cas trop abstraits, une variante directement liée à notre tri de billes. Imaginons que le sac principal (A) puisse contenir d’autres sacs, plus petits (B et C), eux-mêmes remplis de billes mélangées.
Dans ce cas, au moment de prendre un élément, on peut tomber soit sur une bille, soit sur un sac. Si c’est une bille, on applique la logique habituelle. Si c’est un sac, on applique exactement le même processus que pour le sac initial, mais à partir de cette nouvelle pioche. Autrement dit, on ne change pas la logique : on la réutilise telle quelle, quel que soit le niveau. Chaque sac devient alors un nouveau point de départ, traité avec les mêmes règles, jusqu’à ce qu’il n’y ait plus ni billes ni sacs à traiter, autrement dit lorsque le sac initial est entièrement vidé. Cette manière de réappliquer une même logique à des structures imbriquées correspond à ce que l’on retrouvera plus tard dans certains cas de récursivité, ici simplement esquissés sans en faire un point central.
Pour la suite, nous allons rester volontairement dans un cadre plus simple. Nous partirons de l’idée que le sac ne contient que des billes. Cette variante, bien que réaliste, n’est pas nécessaire ici pour comprendre la logique. L’objectif est de garder une lecture claire et directe, sans ajouter de complexité inutile à ce stade.
Donner une structure à la logique
On commence à voir quelque chose se clarifier. Ce que nous faisions presque intuitivement commence à prendre une forme plus stable. On ne se contente plus d’enchaîner des actions, on commence à voir comment elles s’articulent entre elles. Plutôt que de chercher une écriture technique, on peut simplement poser une version plus lisible de ce que nous faisons déjà. Une sorte de fil conducteur que l’on pourrait suivre sans hésiter, du début à la fin. On retrouve alors plusieurs repères, qui ne sont pas là pour compliquer les choses, mais pour éviter de se perdre en cours de route :
- une entrée contrôlée, qui consiste à vérifier que l’on a bien quelque chose à traiter. Ici, cela revient à s’assurer que le tableau de couleurs existe et que le sac contient encore des billes. Sans cette étape, on risque de démarrer un processus vide ou incohérent
- une boucle principale, qui donne le rythme. C’est elle qui nous fait reprendre une bille, puis une autre, sans avoir à réécrire la même logique. Elle évite les oublis et garantit que tout le sac sera traité
- une boucle interne, plus discrète, mais tout aussi importante. Elle correspond au moment où, pour une bille donnée, on parcourt les couleurs attendues. Elle permet de comparer, une à une, sans mélanger les étapes
- des points pivots, ces moments très courts où tout se joue : on prend une bille, on compare, on décide. Ce sont eux qui structurent réellement le processus, car ils marquent les passages d’un état à un autre
- une sortie unique, qui donne une fin claire. On sait exactement quand s’arrêter, sans ambiguïté, lorsque toutes les billes ont été traitées
Ce qui change ici, ce n’est pas la logique elle-même, mais la manière de la percevoir. On passe d’une suite d’actions à un enchaînement structuré, que l’on peut relire, expliquer, et faire évoluer plus facilement. C’est ce passage qui fait le lien entre une idée posée sur le papier et un code que l’on pourra écrire sans se perdre.
Mettre la logique en forme de manière complète
Maintenant la logique est suffisamment stable pour être écrite de manière « complète » et suivie. On peut donc esquisser une version finalisée du processus qui soit lisible et stable :
- vérifier qu’un tableau de couleurs à trier est défini, sinon aller en 9
- reste-t-il des billes dans le sac, sinon aller en 9
- prendre une bille
- prendre la première couleur du tableau
- la bille est-elle de cette couleur
- si oui, placer la bille dans le sac correspondant, puis revenir en 2
- s’il reste une couleur non encore testée, prendre cette couleur, puis retourner en 5
- sinon, placer la bille dans un sac de rebut, puis revenir en 2
- le programme est terminé
Ce processus met en évidence une entrée sécurisée (1), qui garantit que les données nécessaires sont présentes avant de démarrer, puis une boucle principale contrôlée (2), qui assure le parcours complet des billes jusqu’à épuisement du sac. À l’intérieur de cette boucle, une seconde boucle intervient, plus discrète mais essentielle (4) : elle permet de parcourir les couleurs une à une pour une bille donnée, en structurant la comparaison de manière progressive.
Chaque décision s’appuie ainsi sur un enchaînement clair : prendre une bille, parcourir les couleurs, comparer, puis décider du placement ou du rejet. L’ensemble aboutit à une sortie explicite (9), qui marque la fin du traitement. Ce schéma rend visible la logique des boucles imbriquées et l’enchaînement des décisions, sans dépendre d’un langage, et constitue un pont direct vers sa transcription future aussi bien en JavaScript qu’en PHP.
Simplifier la logique par un accès direct aux couleurs
La première approche repose sur un parcours des couleurs. Elle reste lisible, mais montre ses limites lorsque le nombre de couleurs de billes à trier augmente. On peut alors simplifier la décision en changeant la structure des données. Plutôt que de parcourir une liste, on utilise une correspondance directe entre une couleur et son sac.
- vérifier qu’un tableau de correspondance est défini, sinon fin
- reste-t-il une bille, sinon fin
- prendre une bille
- sa couleur existe-t-elle dans la correspondance
- si oui, placer directement dans le bon sac, puis revenir en 2
- sinon, placer au rebut, puis revenir en 2
Ici, on ne cherche plus, on reconnaît. Une seule vérification suffit. Ce point reste simple à retenir : organiser les données permet souvent de simplifier le traitement. Cette variante n’est pas indispensable pour comprendre la logique initiale. Elle montre simplement qu’un même objectif peut être atteint de plusieurs manières, plus ou moins directes selon les choix faits en amont.
Selon la manière dont on organise ces décisions, le chemin peut se construire étape après étape (1), en testant successivement plusieurs cas, ou au contraire s’appuyer sur une correspondance directe qui évite ces détours (2).
Faire le lien avec le code et les notions essentielles
C’est ici que, certaines notions apparaissent presque d’elles mêmes, parce qu’elles répondent directement à ce que nous sommes en train de faire. La bille que nous venons de prendre devient une information que nous devons conserver le temps de la traiter. Cette idée de nommer clairement ce que l’on manipule fait écho aux évolutions apportées par « ES6 : écrire du JavaScript qui nous ressemble enfin », notamment avec l’usage de const et let pour expliciter l’intention dès la déclaration. Sa couleur aussi. Nommer ces éléments permet de stabiliser la logique. C’est là qu’intervient la notion de variable, « Nommer clairement l’intention : let ou const, mais plus var », ce que nous manipulons à un instant donné, ce que nous devons garder sous la main pour prendre une décision.
Très vite, une autre idée apparaît : la nature de ces informations. Une bille n’est pas une couleur, et une couleur n’est pas une liste de couleurs. Sans entrer dans un formalisme lourd, on peut déjà distinguer quelques grandes familles :
- des valeurs simples, comme un texte (« bleue », « rouge » ou « terre ») ou un nombre 45, 1289, 56.7, 1, …
- des ensembles de valeurs, comme une liste de couleurs, un ensemble de billes,…
- des objets plus riches, comme une bille qui possède plusieurs propriétés (sa couleur, éventuellement d’autres attributs comme sa matière, sa taille… )
Ces distinctions ne sont pas des détails. Elles influencent directement la manière dont on compare, dont on parcourt, et dont on prend des décisions. Comprendre ce que l’on manipule permet d’éviter des erreurs et de rendre la logique plus fiable, avant même de penser à la syntaxe.
set bille = prendreBille()
set couleur = bille.couleur // "bleue" ou "rouge"
set nombre_de_bille = sac_de_bille.length // 625, 12678, mais pas 56.7
bille = { "couleur" : "bleue", "matiere" : "terre", "diametre" : 20 }
set couleursATrier = ["bleue", "verte", "jaune"]
set est_ce_une_bille = true // ou false s'il s'agit d'un sac par exempleLe tableau des couleurs à trier n’est plus seulement une idée, mais une structure organisée « Dire ce qu’on veut récupérer, pas ce qu’on va chercher ». Cette manière de manipuler des ensembles de données se retrouve ensuite dans des outils comme la déstructuration ou le spread operator présentés dans « Manipuler sans dupliquer : faire circuler les valeurs », qui permettent de lire et transformer ces structures plus directement. Il regroupe plusieurs valeurs, que nous allons parcourir une à une. Cette logique de parcours et de transformation est détaillée dans « Parcourir et manipuler des objets efficacement avec JavaScript ».
Dans notre cas, il contient simplement des couleurs, ce qui reste volontairement simple. Mais ce choix n’est pas anodin : il prépare déjà une évolution du raisonnement. Selon la structure retenue, tableau, objet, table de correspondance, la manière d’accéder à l’information et donc de décider pourra changer. Nous allons justement voir, dans la section suivante, comment cette organisation influence la logique de l’algorithme. Il pourrait tout aussi bien contenir des nombres, des objets plus complets (par exemple { couleur: « bleue », matiere: « terre » }) ou même d’autres structures, voir « Parcourir et manipuler des objets efficacement avec JavaScript ». L’idée à retenir ici n’est pas la complexité du contenu, mais le fait que l’on manipule un ensemble de valeurs de manière cohérente.
set couleursATrier = ["bleue", "verte", "jaune"]
set billeATrier = [ [couleur: "bleue", matiere: "terre"], [couleur: "verte", matiere: "verre"], /* ... */ ]Ici, la forme des données peut varier selon ce que l’on manipule. Une bille peut être représentée par un objet contenant diverses propriétés, ou seulement une simple couleur. La syntaxe devra s’adapter à cette nature : accès à une propriété, parcours d’un tableau, comparaison de valeurs. Mais la logique, elle, ne change pas : on met toujours en regard deux éléments, deux états, pour décider. Dans la suite, cette même logique va apparaître sous une autre forme, celle des répétitions.
Le fait de reprendre une bille, puis une autre, jusqu’à épuisement du sac, correspond à une boucle. Le fait de tester chaque couleur pour une même bille en est une autre. Ces répétitions traduisent simplement une action que l’on reproduit tant qu’une condition reste vraie.
while ilResteDesBilles():
set bille = prendreBille()
// traitement de la billeSans entrer dans les détails de chaque langage, ce repère suffit pour comprendre l’intention commune derrière les différentes syntaxes. Il existe plusieurs manières d’exprimer une boucle, selon la manière dont on souhaite parcourir les données. Cette façon de formuler une intention plutôt qu’une mécanique rejoint directement ce que nous verrons dans l’article « ES6 : écrire du JavaScript qui nous ressemble enfin », où la syntaxe moderne permet de rendre cette logique plus lisible. On peut parcourir un ensemble avec une forme explicite d’itération, comme for avec un compteur, ou une forme plus directe comme foreach qui parcourt les éléments d’un tableau. La boucle while, utilisée ici, s’appuie sur une condition et se répète tant qu’elle reste vraie. Ces variantes changent la forme d’écriture, mais pas l’intention : répéter une action de manière contrôlée. Pour approfondir ces différentes manières de parcourir des structures et leur impact sur la lisibilité, dans des cas concrets proches de ceux que nous rencontrons en pratique, on peut se référer à l’article « Parcourir et manipuler des objets efficacement avec JavaScript », qui explore ces approches sur des cas plus concrets.
Les tests de condition prennent également une place centrale. La bille est elle de cette couleur, reste-t-il des billes, reste-t-il des couleurs à tester. Chaque question introduit une bifurcation, et donc un choix dans le déroulement.
if couleur == "bleue":
placerDansSac("bleu")
else:
// continuer
// Lorsque ces choix se multiplient, une chaîne de if / else peut devenir verbeuse et moins lisible, car chaque cas est testé successivement :
if (couleur === "bleue") {
placerDansSac("bleu");
} else if (couleur === "verte") {
placerDansSac("vert");
} else if (couleur === "jaune") {
placerDansSac("jaune");
} else {
placerDansRebut();
}Dans ce type de situation, lorsque les correspondances sont connues à l’avance, on peut adopter une écriture plus directe avec une structure de correspondance. Elle évite l’enchaînement des tests et rend la lecture plus concise :
switch (couleur) {
case "bleue":
placerDansSac("bleu");
break;
case "verte":
placerDansSac("vert");
break;
default:
placerDansRebut();
}Dans les deux cas, la logique reste identique : comparer, décider, agir. Seule la forme change. Le if / else est plus souple lorsque les conditions sont variées ou imbriquées. Le switch devient plus lisible lorsque l’on associe une même valeur à plusieurs cas bien définis.
Les fonctions peuvent ensuite être vues comme une manière d’isoler certaines étapes, une approche que l’on retrouve dans « Fonctions fléchées : éviter les pièges de this », où les fonctions fléchées permettent d’exprimer des actions simples sans alourdir la lecture. par exemple le fait de classer une bille ou de tester une couleur, afin de rendre l’ensemble plus lisible et réutilisable.
function classerBille(bille, couleur):
// logique de classement de la bille en fonction de la couleurLes objets pourront être abordés un peu plus loin comme une manière d’organiser ces données et ces actions ensemble. Concrètement, cela reviendra à regrouper ce qui va de pair : une bille et ses propriétés, mais aussi les opérations que l’on effectue sur elle. On ne manipule alors plus des éléments isolés, mais des ensembles cohérents, plus faciles à lire, à faire évoluer et à réutiliser. À ce stade, ce n’est pas indispensable pour comprendre la logique que nous posons ici. L’idée est simplement d’ouvrir cette perspective : structurer ce que l’on manipule permet souvent de simplifier ce que l’on fait.
À partir de là, la logique commence à se structurer naturellement, On peut la résumer autour de quatre éléments simples, qui reviennent constamment :
- Variables / données : elles stockent des informations et décrivent des états à un instant donné ; ce sont elles que l’on observe, que l’on compare, que l’on fait évoluer.
- Actions : on les enchaîne pour faire avancer le processus, prendre, déplacer, transformer, organiser ; elles correspondent aux opérations appliquées aux éléments.
- Comparaisons / conditions : elles permettent de décider, vérifier, orienter le déroulement ; si une valeur correspond, si un état est atteint, alors une direction est prise.
- Boucles : elles répètent ces actions de manière contrôlée, tant qu’une condition reste valide, jusqu’à épuisement des éléments à traiter ou atteinte d’un objectif.
Ensemble, ces éléments constituent une véritable grammaire : un ensemble d’outils simples qui, combinés, permettent de décrire un raisonnement complet, du point de départ jusqu’au résultat.
Transcrire la logique en JavaScript ou en PHP
À partir de là seulement, une fois que la la logique est posée et les passerelles vers le code définies. Il devient alors possible de la traduire dans un langage sans modifier sa structure. Ce passage peut sembler technique au premier regard, mais en réalité, rien de nouveau n’apparaît : on retrouve simplement, sous une autre forme, les mêmes étapes que celles que nous venons de poser. Ce que nous avons construit reste intact, seule son expression évolue. Exemple simplifié en JavaScript :
const couleursATrier = ["bleue", "verte", "jaune"];
if (!couleursATrier || couleursATrier.length === 0) {
exit();
}
while (ilResteDesBilles()) {
const bille = prendreBille();
let classee = false;
for (const couleur of couleursATrier) {
if (bille.couleur === couleur) {
placerDansSac(bille, couleur);
classee = true;
break;
}
}
if (!classee) {
placerDansRebut();
}
}La même logique peut être écrite en PHP. Même si le langage change, il ne s’agit pas d’apprendre quelque chose de nouveau ici, mais de reconnaître les mêmes étapes : reprendre une bille, parcourir les couleurs, tester une condition, décider. Les mots et les symboles évoluent, mais le déroulement reste identique. Voici cette même logique exprimée dans un autre langage :
$couleursATrier = ["bleue", "verte", "jaune"];
if (!isset($couleursATrier) || !is_array($couleursATrier) || count($couleursATrier) === 0) {
exit();
}
while (ilResteDesBilles()) {
$bille = prendreBille();
$classee = false;
foreach ($couleursATrier as $couleur) {
if ($bille->couleur === $couleur) {
placerDansSac($couleur);
$classee = true;
break;
}
}
if (!$classee) {
placerDansRebut();
}
}On retrouve les mêmes éléments : une boucle principale, un parcours des couleurs, un test de condition, une sortie anticipée. Seule la syntaxe change, pas la manière de penser. C’est précisément ce que montre aussi « ES6 : écrire du JavaScript qui nous ressemble enfin » : la syntaxe évolue, mais la logique reste stable, simplement mieux exprimée … Écrire mieux, comprendre plus vite…
Ce point mérite d’être formulé clairement : le code n’est jamais qu’une traduction d’une logique déjà décidée. Lorsque nous écrivons en JavaScript ou en PHP, nous ne créons pas la logique, nous la transcrivons. Les mots changent, la structure reste. Cette manière de voir évite de se perdre dans la syntaxe et permet de se concentrer sur l’essentiel, la cohérence du raisonnement.
Rendre le code lisible : commentaires et intentions
Un point souvent sous-estimé accompagne cette traduction : commenter, c’est expliquer l’intention, pas répéter le code. Autrement dit, les commentaires ne décrivent pas la syntaxe, ils éclairent le raisonnement : pourquoi on fait ce choix, ce que l’on cherche à éviter, et dans quel cas cela change. Ils permettent de comprendre rapidement une logique sans devoir relire chaque ligne en détail, et deviennent essentiels dès que le code évolue ou est partagé. Ils peuvent aussi servir à signaler ce qui reste à faire ou ce qui est volontairement simplifié à ce stade :
// TODO : gérer les cas où la bille n’a pas de couleur
// TODO : optimiser la recherche si le nombre de couleurs augmenteCes repères ne sont pas là pour alourdir l’écriture, mais pour maintenir une lecture claire dans le temps. Un code lisible est un code que l’on peut reprendre, comprendre, corriger et faire évoluer sans repartir de zéro. C’est cette exigence simple qui accompagne naturellement la logique que nous venons de poser.
// on parcourt les couleurs une à une pour comparer avec la bille en cours
for (const couleur of couleursATrier) {
// test : est-ce que la couleur de la bille correspond à celle que l’on regarde
if (bille.couleur === couleur) {
// action : on place immédiatement la bille dans le bon sac
placerDansSac(couleur);
// choix important : on s’arrête dès la première correspondance
// cela évite de continuer à comparer inutilement
break;
}
}// à ce stade, toutes les couleurs ont été testées pour la bille
// si aucune n’a correspondu, on considère qu’elle ne fait pas partie des cas attendus
if (!$classee) {
// décision : on envoie la bille dans le rebut
placerDansRebut();
}
Dans ces exemples, les commentaires ne répètent pas le code, ils mettent en lumière les moments clés : le test, la décision, l’arrêt du processus. C’est ce qui permet, en relisant, de comprendre rapidement l’intention globale sans devoir analyser chaque ligne. Nous avons posé une logique, l’avons structurée, puis traduite en code. Ce cheminement reste le même, quel que soit le langage.
Appliquer cette logique dans des situations courantes
On peut garder en tête une idée simple : les langages changent, mais la logique reste. Une même suite d’actions peut être écrite en JavaScript, en PHP ou ailleurs, sans que la manière de penser soit remise en cause. Ce que l’on déplace, ce n’est pas l’algorithme, mais sa forme. Cette approche ne reste pas cantonnée à cet exemple. On la retrouve très concrètement dans des situations que nous manipulons tous les jours.
- Prenons un formulaire. L’utilisateur envoie des données, et une suite de décisions s’enchaîne : est-ce que les champs sont remplis ? est-ce que les valeurs sont valides ? faut-il afficher une erreur ou enregistrer les informations ? Derrière ce fonctionnement, on retrouve exactement la même logique : une entrée, des tests de condition, puis une décision qui oriente la suite du traitement.
- Autre cas courant, une interface en accordéon. Un seul bloc doit être ouvert à la fois. Lorsqu’un utilisateur clique, on doit vérifier quel bloc est actif, fermer les autres, puis ouvrir celui demandé. Là encore, il s’agit d’un enchaînement d’états et de conditions : si un bloc est ouvert, alors le fermer, puis activer le nouveau. Rien de graphique dans l’intention, uniquement une logique de contrôle.
- Enfin, un tri simple, comme un tri à bulle. On compare deux valeurs, on les échange si elles ne sont pas dans le bon ordre, puis on recommence jusqu’à ce que l’ensemble soit correctement classé. Ce processus repose sur une boucle, des comparaisons répétées et une condition d’arrêt lorsque plus aucun échange n’est nécessaire.
Dans chacun de ces cas, on retrouve les mêmes briques : des variables que l’on manipule, des conditions qui orientent, des boucles qui répètent, et des décisions qui structurent le flux.
Progressivement, l’algorithmique cesse d’être un sujet isolé. Elle devient une manière de lire et d’écrire le code, un fil conducteur qui traverse les langages et les projets, et qui permet de garder une cohérence, même lorsque les outils évoluent.
Conclusion, prolonger la logique dans la pratique
La logique que nous avons construite ici ne s’arrête pas à cet exemple. Elle constitue un point de départ. Une manière de poser un raisonnement, de structurer une suite d’actions, puis de la reconnaître dans des situations plus concrètes. À partir de ce socle, il devient possible d’explorer. Reprendre cette même logique avec d’autres cas, filtrer des données issues d’un formulaire, parcourir une liste d’éléments, organiser un affichage dynamique. Chaque nouvelle situation vient confirmer que ce qui a été posé tient, et surtout peut être réutilisé.
C’est dans cette répétition que quelque chose s’installe. Non pas une suite de règles à mémoriser, mais une manière de penser. Progressivement, les choix deviennent plus naturels. On anticipe mieux les cas, on structure plus vite, on simplifie ce qui peut l’être. Le code ne devient alors qu’un support parmi d’autres. JavaScript, PHP, Python, SQL, Shell… ou tout autre langage n’imposent pas une logique, ils l’expriment. Ce que nous écrivons reste le prolongement direct de ce que nous avons déjà organisé.
La suite consiste donc à multiplier ces situations, à tester, à ajuster, à confronter ses choix… jusqu’à ce que cette manière de penser devienne naturelle. C’est dans cette pratique que l’algorithmique prend réellement sa place, non comme une notion isolée, mais comme un fil conducteur qui accompagne chaque projet.
