Lors de la pro­gram­ma­tion d’une ap­pli­ca­tion, d’un logiciel IdO ou d’un jeu vidéo, avant même l’écriture des premières lignes de code, les dé­ve­lop­peurs doivent sé­lec­tion­ner le langage de pro­gram­ma­tion qu’ils sou­hai­tent utiliser. Plusieurs choix s’offrent à eux. Avec du recul, on se rend toutefois compte que tous ces langages sont répartis en deux pa­ra­digmes de pro­gram­ma­tion de base : la pro­gram­ma­tion dé­cla­ra­tive et la pro­gram­ma­tion im­pé­ra­tive.

Qu’est-ce que la pro­gram­ma­tion dé­cla­ra­tive ?

Bien que ce paradigme ne soit pas clai­re­ment défini, toutes les dé­fi­ni­tions s’accordent sur un point : la ca­rac­té­ris­tique des langages de pro­gram­ma­tion dé­cla­ra­tive est qu’ils décrivent toujours le résultat final souhaité, plutôt que d’énoncer les dif­fé­rentes étapes à mettre en œuvre. Dans le cadre de la pro­gram­ma­tion dé­cla­ra­tive, pour atteindre l’objectif énoncé, les étapes de ré­so­lu­tion sont dé­ter­mi­nées de manière au­to­ma­tique. Cela fonc­tionne bien dès lors que les spé­ci­fi­ca­tions du résultat final sont clai­re­ment définies et qu’il existe une procédure d’exécution adaptée. Le cas échéant, la pro­gram­ma­tion dé­cla­ra­tive est des plus efficaces.

Dans la mesure où la pro­gram­ma­tion dé­cla­ra­tive ne définit pas clai­re­ment le « dé­rou­le­ment », mais fonc­tionne à un niveau d’abs­trac­tion très élevé, le paradigme de pro­gram­ma­tion laisse en outre une marge d’op­ti­mi­sa­tion. Si un meilleur procédé d’exécution est mis au point à l’avenir, l’al­go­rithme intégré le dé­cou­vrira et l’ap­pli­quera. Ce paradigme est ainsi très évolutif : lors de l’écriture du code, la marche à suivre pour atteindre le résultat n’est pas définie de manière fixe.

Les langages de pro­gram­ma­tion dé­cla­ra­tive les plus connus sont :

  • Prolog
  • Lisp
  • Haskell
  • Miranda
  • Erlang
  • SQL (au sens large)

Les dif­fé­rents langages de pro­gram­ma­tion peuvent encore être répartis en deux pa­ra­digmes : les langages de pro­gram­ma­tion fonc­tion­nelle et les langages de pro­gram­ma­tion logique.

Au quotidien, les limites entre ces langages sont bien souvent floues. Tant les éléments de pro­gram­ma­tion im­pé­ra­tive et leurs sous-ca­té­go­ries de pro­gram­ma­tion pro­cé­du­rale, modulaire et struc­tu­rée, que ceux de pro­gram­ma­tion dé­cla­ra­tive peuvent être appliqués à la ré­so­lu­tion de problèmes.

Image: Aperçu de la systématisation au sein des paradigmes de programmation impérative et déclarative
En principe, les langages de pro­gram­ma­tion peuvent être associés à deux pa­ra­digmes de pro­gram­ma­tion contenant, à leur tour, leurs propres styles de pro­gram­ma­tion.

Com­pa­rai­son entre les pro­gram­ma­tions im­pé­ra­tive et dé­cla­ra­tive

Le paradigme de pro­gram­ma­tion im­pé­ra­tive (paradigme axé sur les commandes) est le paradigme de base le plus ancien des deux. À l’inverse de la pro­gram­ma­tion dé­cla­ra­tive, le dé­ve­lop­peur définit ici pré­ci­sé­ment, dans le code source, chacune des étapes à exécuter par l’or­di­na­teur pour aboutir au résultat. Le « dé­rou­le­ment » prime. Cette approche se retrouve, par exemple, dans les langages de pro­gram­ma­tion Java, Pascal ou C. La pro­gram­ma­tion dé­cla­ra­tive, au contraire, se concentre di­rec­te­ment sur l’« objectif » à atteindre.

Voici un exemple d’ap­pli­ca­tion dans le domaine du montage de meubles : alors que la pro­gram­ma­tion im­pé­ra­tive s’apparente à une notice de montage, la pro­gram­ma­tion dé­cla­ra­tive donne pour modèle une image du meuble fini.

Plutôt que de laisser une marge d’exécution par l’uti­li­sa­tion de dif­fé­rentes fonctions, la pro­gram­ma­tion im­pé­ra­tive utilise des variables qui sont trans­for­mées en durée d’exécution. Le code est plus long, mais aussi plus facile à com­prendre que la forme abrégée et très abstraite du style dé­cla­ra­tif.

Exemple de pro­gram­ma­tion dé­cla­ra­tive

Une force de la pro­gram­ma­tion dé­cla­ra­tive est sa capacité à décrire les problèmes de manière plus abrégée et syn­thé­tique que les langages im­pé­ra­tifs.

Pour obtenir une liste de prénoms, la pro­gram­ma­tion dé­cla­ra­tive, comme le montre l’exemple, peut, dans le PHP, décrire en une seule ligne de code ce que la procédure im­pé­ra­tive décrirait en cinq lignes.

Pro­gram­ma­tion im­pé­ra­tive 

$Listeparticipants = [1 => 'Pierre', 2 => 'Paul', 3 => 'Sarah'];
$prénom = [];
foreach ($Listeparticipants as $id => $nom) {
    $prénom[] = $nom;
}

Pro­gram­ma­tion dé­cla­ra­tive

$prénom = array_values($Listeparticipants);

Avantages et in­con­vé­nients des langages de pro­gram­ma­tion dé­cla­ra­tive

De nos jours, la pro­gram­ma­tion dé­cla­ra­tive est utilisée dans un grand nombre de cas, même si elle n’est alors pas toujours employée dans sa forme la plus pure. Cependant, cette approche n’est pas adaptée à toutes les uti­li­sa­tions.

Le code dé­cla­ra­tif se distingue par un niveau d’abs­trac­tion élevé. Les dé­ve­lop­peurs peuvent ainsi écrire des pro­grammes complexes sous forme syn­thé­tique. Le cas échéant, plus l’ap­pli­ca­tion est vo­lu­mi­neuse, plus le code risque d’être imbriqué au point de ne plus être lisible que par son dé­ve­lop­peur d’origine. Pour les en­tre­prises gérant et sou­hai­tant pour­suivre le dé­ve­lop­pe­ment d’ap­pli­ca­tions de manière in­dé­pen­dante, cette situation re­pré­sente un danger. Les dé­ve­lop­peurs tiers doivent en effet déployer de gros efforts pour dé­chif­frer le code dé­cla­ra­tif, en com­prendre la structure et résoudre les problèmes.

Cela dit, le niveau d’abs­trac­tion de la pro­gram­ma­tion dé­cla­ra­tive présente également des avantages. L’exécution étant clai­re­ment séparée du système par un al­go­rithme, la main­te­nance peut être exécutée in­dé­pen­dam­ment du dé­ve­lop­pe­ment de l’ap­pli­ca­tion. Au quotidien, les per­tur­ba­tions d’ex­ploi­ta­tion sont réduites au minimum. Dans le même temps, l’op­ti­mi­sa­tion du code est plus simple, car l’al­go­rithme utilisé est suf­fi­sam­ment ouvert pour permettre le recours à de nouvelles méthodes. L’in­con­vé­nient de l’uti­li­sa­tion d’un al­go­rithme : dans certaines cir­cons­tances, une solution formelle peut n’aborder que par­tiel­le­ment des ca­rac­té­ris­tiques spé­ci­fiques de dif­fé­rents cas d’ap­pli­ca­tion.

Cela ne re­pré­sente pas forcément un in­con­vé­nient en tant que tel, mais s’impose comme un défi dans le modèle de pensée de la pro­gram­ma­tion dé­cla­ra­tive. Penser en termes de solution va à l’encontre du processus de pensée humaine naturelle. Les hommes ont tendance à réfléchir aux étapes de processus menant à un objectif, plutôt qu’à partir de l’objectif pour remonter jusqu’à la situation initiale. Les dé­ve­lop­peurs doivent ici changer leur mode de pensée, ce qui, dans un premier temps, peut ralentir la ré­so­lu­tion de problèmes. Mais une fois cette nouvelle approche acquise, il est enfin possible d’exploiter au maximum les atouts de l’approche dé­cla­ra­tive.

Le dé­ve­lop­pe­ment d’une solution à partir de la des­crip­tion d’un problème présente également l’avantage de permettre aux équipes d’esquisser assez ra­pi­de­ment des modèles de solution. La pro­gram­ma­tion concrète de l’exécution peut en outre avoir lieu à une étape ul­té­rieure. Le style dé­cla­ra­tif est par­ti­cu­liè­re­ment adapté au pro­to­ty­page dans le cadre du dé­ve­lop­pe­ment de logiciels agiles.

Avantages In­con­vé­nients
Code plus court et plus efficace Parfois difficile à com­prendre par des tiers
Exé­cu­table par des méthodes encore inconnues au moment de la pro­gram­ma­tion Se fonde sur un modèle de pensée in­ha­bi­tuel pour l’homme (état de la solution)
Op­ti­mi­sa­tion facile, grâce à la gestion de l’exécution par al­go­rithme Les ca­rac­té­ris­tiques de dif­fé­rents cas d’ap­pli­ca­tion ne peuvent que dif­fi­ci­le­ment être prises en con­si­dé­ra­tion dans la pro­gram­ma­tion
Main­te­nance possible in­dé­pen­dam­ment du dé­ve­lop­pe­ment de l’ap­pli­ca­tion  

Au jour le jour, on utilise souvent des com­bi­nai­sons de ces pa­ra­digmes, les langages de pro­gram­ma­tion dé­cla­ra­tive étant alors gé­né­ra­le­ment complétés par des méthodes im­pé­ra­tives. Cela peut toutefois augmenter la pro­ba­bi­lité d’erreur et affecter la li­si­bi­lité du code.

Aller au menu principal