Routage automatisé: principes de base

Les ordinateurs de bord procurent des avantages indéniables. Une de ces avantage est le routage automatisé, soit le calcul d’une trajectoire de voile basée sur des prévisions météo. Le navigateur fournit d’abord à l’ordinateur un point de départ et un point d’arrivée, puis une route à temps minimal est calculée pour chacun des scénarios météorologiques disponibles. L’ordinateur présente autant de routes qu’il y a de modèles météo. Ces calculs sont extrêmement utiles pour analyser des chemins possibles.

Les routes automatisées sont calculés notamment sur des applications telles qu’OpenCPN, gratuite (mais qui demande beaucoup d’ajustements), ou ecore PredictWind, où un abonnement mensuel est requis (mais qui est plus facile d’usage). Il existe probablement d’autres applications qui offrent des fonctionnalités similaires.

Ce texte montre comment les ordinateurs trouvent les routes optimales. Il fait également le pont entre différentes méthodes mathématiques servant aux calculs, souligne les avertissements d’usage – notamment en matière de sécurité-, et discute de quelques dimensions pratiques. La bonne nouvelle est que tout ce qui est requis pour comprendre ce texte est la capacité de faire des additions et un peu de jugement.

Principe de base

Tout logiciel de routage automatisé identifie la route qui prend le moins de temps. Ils ne font rien de plus, rien de moins!

Pour ancrer les idées, nous allons employer l’image ci-dessus, où le point de départ est le point 1 et le point d’arrivée est le point 31. L’image représente une carte rudimentaire où le bleu est de l’eau et le jaune est une zone terrestre. On voit donc un plan d’eau à vol d’oiseau.

On pense souvent à la voile de manière romancée. On rêve à la grande liberté qu’elle procure en permettant de choisir son chemin sur une vaste étendue d’eau. On rêvera ainsi à l’infinité de routes possibles reliant le point de départ (point 1) au point d’arrivée (point 31).

L’ordinateur est plus terre à terre. Il se construit une grille de points intermédiaires et n’examine les chemins qui ne passent que sur cette grille. La restriction qu’impose l’ordinateur peut sembler réductrice a priori, mais sa grille a tellement de points qu’elle est peu limitative. Par contre, cette approche lui permet de structurer le problème.

Comme l’objectif est de comprendre comment raisonne l’ordinateur de bord, je vais supposer qu’il n’existe que 29 points intermédiaires par où le voilier peut passer. Seulement le nombre limité de routes qui sont entre ces points sera permis. Cette approche tient compte de nos capacités humaines de calcul, mais pour la romance et la liberté des chemins à prendre, on repassera!

Cette première simplification est illustrée ci-dessous. Les point intermédiaires sont numérotés de 2 à 30 et les routes intermédiaires sont représentés par des flèches. Il est ainsi possible de naviguer du point 5 au point 7, mais il est impossible de naviguer du point 8 au point 9 (aucune flèche).

Cette restriction est bien sûr pédagogique. L’ordinateur emploie un nombre de point très élevés (des milliers) avec un nombre encore plus important de routes intermédiaires. Dans ce qui suit, l’important est de comprendre comment on identifie la route parmi les chemins possibles. Si on fournit à l’ordinateur une grille avec des milliers de chemins possibles, le processus d’identification sera le même que ce qui est exposé ci-dessous. Ce processus est ce qu’on appelle un algorithme.

Je vais également supposer que la météo est stable pendant la durée de la navigation. Cela permet de calculer le temps de déplacement sur chaque route possible avant le début du trajet. Ce faisant, les calculs se présentent en une image.

Évidemment, les ordinateurs de bord ne présument pas que la météo est constante. Ils calculent plutôt le temps de déplacement en fonction de la météo au moment où le bateau est sur la route intermédiaire. Ce faisant, les ordinateurs de bord présentent les trajectoires à temps minimal à l’aide de vidéos, illustrant l’effet de la météo à chaque période de transit.

Avec cette simplification, le temps de déplacement pour chacune des routes intermédiaires, estimé en heures, est illustré ci-dessous. Ainsi, il faut 0.5 heures (30 min) pour naviguer du point 1 au point 2, ou encore 0.4 heures (24 min) pour naviguer du point 7 au point 11.

Le temps total de navigation est bien sûr cumulatif, ce qui veut dire que pour se rendre d’un point à un autre point, il faut additionner l’ensemble du temps requis sur le chemin emprunté. Par exemple, pour aller du point 1 au point 15, il faut un total de 0.8 h (48 min), soit la somme de 0.3 heure et de 0.5 heure.

Si vous en avez envie, essayez d’identifier manuellement dans l’image ci-dessus quelle route prend le moins de temps entre le point 1 et le point 31. Le nombre de chemins est suffisamment petit pour être capable de l’identifier « à l’œil ».

La solution, qui consiste à emprunter les points intermédiaires 2, 5, 7, 12, 20, 26 et 30, est présentée à l’image ci-dessous (en vert). Elle requiert 2.8 heures de navigation (2h 48 min). N’importe quelle autre route prendra nécessairement plus de temps!

Si les personnes peuvent identifier une solution « à l’œil » sur des petits problèmes, elles en deviennent rapidement incapables quand le nombre de chemins intermédiaires augmente. Comment s’y prennent les ordinateurs pour identifier cette route? Ils n’ont pas « d’œil » et sont de surcroît très mauvais pour identifier des solutions heuristiques. En revanche, ils sont très rapides. Si on leur montre comment se servir d’une caractéristique fondamentale de toute route à temps minimal, ils pourront systématiquement identifier la solution exacte en très peu de temps. Ce principe, d’application beaucoup plus générale que ce que ce texte ne laisse croire, peut se résumer en une phrase.

Un chemin minimal est nécessairement minimal en tout point

Cette phrase signifie que si on prend deux points quelconques le long du trajet à temps minimal, alors le trajet entre ces deux points doit aussi être à temps minimal. S’il existait au contraire un chemin qui prenait moins de temps entre ces deux points, alors le chemin original pourrait être raccourci en remplaçant ce chemin plus court. Le chemin original ne serait donc pas à temps minimal. (Relisez au besoin).

Ce faisant, tout chemin à temps minimal doit nécessairement consister en une suite de chemins à temps minimaux entre chaque point du trajet. Le principe est illustré à l’image ci-dessus, qui se concentre sur la recherche du chemin entre le point 5 et le point 12.

On peut identifier plusieurs routes possibles:

• La route 5 \to 6 \to 9 \to 12 (en orange, pour 1 h 12 min);
• La route 5 \to 8 \to 12 (en rouge, pour 54 min);
• La route 5 \to 7 \to 12 (en vert, pour 48 min);
• La route 5 \to 6 \to 8 \to 12 (de couleur mixte, pour 1 h);
• La route 5 \to 7 \to 11 \to 12 (verte et noire, pour 1 h 12 min);
• La route 5 \to 7 \to 10 \to 11 \to 12 (verte et noire, pour 1 h 24 min);

Calculer le temps sur chacune de ces routes est extrêmement simple. On peut identifier immédiatement que le temps minimal est de 48 minutes par le trajet en vert. On peut donc immédiatement déduire le fait suivant: si la route à temps minimal emprunte les points 5 et 12, alors elle passe nécessairement par le trajet 5 \to 7 \to 12. Nous venons tout juste de montrer que le contraire n’est pas possible: tout autre chemin entre 5 et 12 est nécessairement plus long! La route à temps minimal doit aussi être à temps minimal localement. C’est tellement simple que ça en est presque redondant!

Cette idée fondamentale est extrêmement utile parce qu’elle prend un problème général et compliqué – identifier le chemin à temps minimal sur l’ensemble des points -, et elle le décompose en petits problèmes faciles à résoudre: identifier le chemin à temps minimal sur des petits segments intermédiaires. Ce faisant, l’ordinateur peut se concentrer sur l’identification de chemins sur un petit nombre de points – des points voisins par exemple – pour identifier des solutions locales. Il peut ensuite résoudre le problème plus compliqué, sur l’ensemble des points, en collant ces solutions locales entre elles.

Si vous comprenez ce principe, vous y êtes presque. Tout ce qui manque est un point de départ, un livre des comptes… et beaucoup de patience! Si l’ordinateur va très vite, pas nous.

Le livre des comptes

En débutant son calcul, l’ordinateur assigne à chaque point (1 à 31) une valeur de temps de déplacement et le chemin qui a permis de s’y rendre avec ce temps. Au premier point, il assigne une valeur de zéro, signifiant qu’il faut un temps nul pour s’y rendre et assigne un chemin vide. Pour tous les autres points, il présume d’un temps infini (noté \infty) et assigne également un chemin vide. Ces valeurs assignées – durée et chemin – constituent son livre des comptes. Ces valeurs changeront au fur et à mesure que l’ordinateur évaluera les chemins des points intermédiaires.

Le livre des comptes est illustré à l’image ci-dessous, où la durée est inscrite à l’intérieur de chaque nœud (les chemins ne sont pas illustrés). Il est aussi résumé dans un tableau (partiel) après l’image, tableau qui correspond à l’information que stocke l’ordinateur dans sa mémoire.

Du point de départ, l’ordinateur évalue le temps minimal requis pour se rendre à chaque point où il peut naviguer par un chemin direct (une flèche). Du point 1, il peut donc évaluer le temps pour se rendre au point 3 et pour se rendre au point 2. Ici, il commence (arbitrairement) au point 2.

Pour se rendre au point 2, il doit prendre 0.5 heure (30 min) de temps auquel il doit ajouter la durée cumulée au livre des comptes du point par lequel il arrive. Comme il arrive du point 1, le temps cumulé est de zéro et le temps total de transit est donc de 0.5 + 0, soit 0.5 heure (30 min). Il évalue ce temps calculé et le compare à celui stocké au livre des comptes au point intermédiaire d’arrivée (point 2). L’ordinateur retiens alors le plus petit nombre des deux, car par le principe de minimum local, le temps de déplacement entre ces deux points doit être le plus petit.

Le temps enregistré au livre des comptes au point 2 est actuellement un temps infini (\infty). Il note donc le temps de 0.5 heures (30 min) à la place et note le point précédent par lequel il est arrivé (le point 1) au livre des comptes.

Similairement, le temps minimal pour se rendre au point 3 est de 18 minutes (0.3 h). Le livre des comptes est ainsi mis-à-jour avec la durée 0.3 et le point 1. Le livre des comptes à jour est illustré dans l’image ci-dessous et au tableau subséquent.

L’ordinateur recommence ensuite le processus en partant cette fois d’un des deux points qu’il vient tout juste d’évaluer. Il peut arbitrairement commencer au point 3 ou au point 2, et j’illustre ici avec le point 2 (image ci-dessous). Du point 2, encerclé en vert, il peut naviguer soit au point 4 (encerclé en orange), soit au point 5 (encerclé en rouge).

Le temps calculé pour se rendre au point 4 est de 0.9 heure (54 min), soit le temps de transit à partir du point 2 (0.4 h) additionné du temps minimal pour se rendre au point 2 (0.5 h). Comme le temps au livre des comptes est infini pour le point 4, il est mis-à-jour à la valeur de 0.9 heure (54 min) et le point d’arrivé est également noté (non-illustré). Similairement, il met à jour le livre des comptes pour le point 5 en y mettant une valeur de 0.9 heure et le chemin d’arrivée par le point 2. Le tableau à jour est tout juste après l’image.

L’idée est la même pour le point 3 (image ci-dessous). Le livre des comptes à jour permet d’identifier que le temps de déplacement du point 1 au points 14 et 15 est respectivement de 0.5 heure (30 min) et de 0.8 heure (48 min).

Jusqu’à maintenant, l’ordinateur n’a évalué que des routes uniques. Dans ces circonstances, l’identification de la route est plutôt simple, car il n’y a pas de comparaison à faire avec une route alternative. Ce faisant, il remplace toujours l’infini qui est stocké au livre des comptes par le temps de transit calculé.

Quand une route a déjà été calculée pour atteindre un point, les choses sont cependant différentes. Le livre des comptes comprend déjà un temps de transit calculé et un point par lequel l’ordinateur est arrivé. Dans ce cas, c’est possible que le livre des comptes affiche une valeur plus petite à la valeur calculée. En accord avec le principe de minimum local, l’ordinateur va toujours conserver le plus petit nombre des deux. Bien sûr, il gardera au livre des comptes le point d’arrivée qui est cohérent avec ce temps.

Ce cas de figure se produit lorsque l’ordinateur évalue le temps de transit cumulé partir du point 5 (encerclé en rouge dans l’image ci-dessous). À l’évaluation de la route pour se rendre au point 6 (encerclé en vert), il calcule un temps minimal de 1.2 heures (1 h 12 min) pour s’y rendre. En effet, le temps au livre des comptes pour se rendre au point 5 est de 0.9 heure (54 min) et il faut y additionner un temps de trajet de 0.3 heure (18 min) entre les deux points.

Or, pour le point 6, le temps au livre des comptes est calculé à 1.1 heures (1 h 6 min) lorsqu’en provenance du point 4. Par le principe de minimum local, il est impossible que le chemin minimal entre le point 1 et le point 6 passe par le point 5. Ce faisant, l’ordinateur ne remplace pas la valeur au livre des comptes, conserve la valeur minimale d’une heure six minutes (1.1 heure) et conserve le point 4 comme point d’origine pour se rendre au point 6. Le tableau à jour est présenté après l’image.

Ensuite? On répète! L’ordinateur évalue les points découverts et calcule le temps cumulé de transit, toujours en gardant la valeur la plus basse.

Je saute quelques étapes et présente dans l’image ci-dessous l’état du livre des comptes à l’examen du point intermédiaire 20 (encerclé en vert). Les points en mauve correspondent à ceux qui ont été visités par l’ordinateur et les valeurs inscrites correspondent à l’état du livre des comptes. À titre d’exemple, le temps minimal pour se rendre au point 18 (encerclé en rose) est calculé à 1.3 heures (1 h 18 min).

Au point 20, le livre des comptes est calculé à 1.9 heures (1h 54 min). Son nœud d’arrivée est également noté au livre, soit le point 12.

Dans l’exploration du temps requis pour les points où le voilier peut se rendre (25 encerclé en orange, 26 encerclé en jaune et 21 encerclé en rouge), l’ordinateur calcule un temps de transit de 2.2 heures pour le cercle orange (2 h 12 min), de 2.1 heures pour le cercle jaune (2 h 6 min) et de 2.3 heures pour le cercle rouge (2 h 18 min). Ces temps correspondent au temps minimal pour se rendre au point 20 (1.9 h) additionné du temps de chacun des segments (resp. 1.9 + 0.3, 1.9+0.2, 1.9+0.4).

Comme le temps au livre des comptes du point orange est inférieur (2.0 h), on peut déduire que le point 20 ne fait pas partie des chemins minimaux pour s’y rendre. Il ne remplace donc rien au livre des comptes. Par contre, le point encerclé en jaune avait jusqu’à maintenant un temps minimal infini. Comme le temps calculé de 2.1 heures est inférieur, le livre des comptes est amendé pour refléter cette valeur et le point 20 est également noté, signifiant par où l’ordinateur est arrivé. Le tableau à jour est illustré ci-dessous.

Ultimement, l’ordinateur aura visité tous les points intermédiaires possibles (image ci-dessous). Quand ce sera le cas, les valeurs inscrites au livre des comptes aura, pour chaque point, le temps minimal de déplacement à partir du point 1 jusqu’à ce point. On trouvera également à chaque point du livre des comptes le point précédent par lequel il est arrivé. Ainsi, l’image ci-dessous nous renseigne sur le fait que le temps minimal pour se rendre au point 31 est de 2.8 heures (2 h 48 min).

Tout ce qu’il reste à faire est de regarder dans le livre des comptes pour identifier le chemin à l’envers et utilisant la colonne de « point précédent ». L’ordinateur sait ainsi qu’il est arrivé au point 31 par le point 30, puis du point 26 et ainsi de suite jusqu’au point 1. Il peut alors retrouver le chemin à temps minimal et l’afficher à l’écran de l’ordinateur de bord (image ci-dessous).

L’explication du fonctionnement de l’ordinateur de bord a pris quatre ou cinq bonnes pages – environ 20 minutes de lectures – … et nous avons omis des étapes. Mais qu’on ne se méprenne pas: le processeur de calcul de l’ordinateur de bord est tellement performant qu’il trouve ce genre de solutions en une fraction de seconde.

Et les simplifications?

Rappelez-vous qu’en début de texte, j’ai précisé que je simplifiais l’environnement en supposant un nombre restreint de chemins possibles. J’ai également simplifié en supposant la météo constante. Ces simplifications permettaient d’illustrer le principe de fonctionnement en images tout au long de ce texte.

En pratique, l’ordinateur emploie un nombre arbitrairement élevé de points et calcule tous les chemins possibles d’un point voisin à un autre. L’image ci-dessous illustre une grille avec un peu moins de 150 points. Cette grille comprend un peu moins de 12 000 chemins intermédiaires possibles. Je laisse à quelqu’un d’autre le soin de les illustrer!

Le chemin à temps minimal sur cette grille prend toujours une fraction de secondes à calculer par l’ordinateur, mais on a maintenant une grille beaucoup moins contraignante pour identifier le chemin à temps minimal. C’est le retour de la romance! Parce que la distance entre les points est plus petite, le chemin à temps minimal est beaucoup plus proche de la véritable liberté d’action dont dispose un voilier. C’est plus long à calculer (et ce n’est pas un exercice plaisant à faire manuellement!), mais la solution est identifiée en employant exactement le même principe que ce qui est illustré dans ces pages.

Ce n’est pas assez précis? Il suffit d’augmenter le nombre de points! Éventuellement, la grille sera tellement serrée que ça ne fera plus aucune différence pratique…. au prix d’un temps de calcul un peu plus élevé.

Pour ce qui est de la météo, ça ne fait aucune différence pour l’ordinateur. J’ai supposé la météo constante pour illustrer les temps de déplacement entre les points en une seule image. C’est plus facile à visualiser. De son côté, l’ordinateur n’a pas d’image à produire, si bien qu’il peut calculer les temps de déplacement en fonction de la météo au moment où le voilier arrive au point intermédiaire. Pour l’ordinateur, ce n’est qu’un calcul à faire à chaque étape plutôt que de faire l’ensemble au début. C’est évidemment une approche beaucoup plus générale, mais elle est plus difficile à mettre en images!

Quelques commentaires plus avancés

Cette section fait le pont entre différentes méthodes mathématiques employées pour identifier le chemin optimal selon différentes disciplines. Les personnes moins familières avec les mathématiques avancées devraient sauter cette section et se rendre à la suivante.

L’algorithme illustré dans ce texte revient à Disjktra et fait partie des algorithmes « fondateurs » de la science informatique (ou de la science de la décision). C’est la solution d’un problème de trajectoire optimale sur un graphe et elle a le principal avantage de ne demander qu’une compréhension de l’addition, du principe de minimum local… et de la répétition.

Alternativement, l’algorithme de Disjktra peut être vu comme une solution à un problème de contrôle optimal standard où la trajectoire optimale s(p_0, p_T) satisfait:

s(p_0, p_T) = \min_j\left[ D(p_0, p_j) + s(p_j, p_T)\right].

Dans cette expressions, D(p_i, p_j) est le temps de transit entre deux points intermédiaires. Cette expression satisfera bien sûr la version discrète de la condition de Bellman et la formulation fait explicitement référence, par l’additivité récursive, au principe de minimum local: la fonction est globalement minimale si c’est le trajet à durée minimale connectant un point additionnel à un trajet déjà minimisé.

On peut aussi représenter le problème sur des semi-anneaux max-plus, ce qui a l’avantage de linéariser le problème. Ce faisant, la solution optimale est le vecteur propre associé à la valeur propre unitaire de la matrice associée au problème. Cette approche est extrêmement performante sur des ordinateurs embarqués, car la linéarité implique que les calculs se parallélisent.

Finalement, la plupart des travaux empiriques portant sur les tactiques de régates et les trajectoires optimales à voile travaillent avec les équations d’Euler-Lagrange (probablement parce la plupart des tacticiens viennent des sciences physiques). L’approche est conceptuellement plus attrayante parce qu’elle modélise la trajectoire de voile par une fonction continue, différentiable et évite la conversation de « simplification » de l’environnement en imposant un nombre restreint de chemin. En revanche, l’approche demande de comprendre les équations différentielles et les solveurs numériques.

En pratique, on résout les équations d’Euler-Lagrange avec l’équation différentielle associée (et en employant l’identité de Beltrami), assujetties aux conditions terminales du point de départ et du point d’arrivée. Or, tout solveur numérique discrétisera l’espace sur lequel on représente l’équation différentielle. Par le principe de dualité, la solution identifiée sera exactement le même que celle de l’algorithme de Disjktra (si la discrétisation est la même). J’ai donc illustré ici une représentation différente de cette approche, qui mène à la même solution, mais qui est plus simple à comprendre.

De retour à la programmation principale.

Ce que l’ordinateur ne fait pas

À la base, l’ordinateur ne fait qu’une et une seule chose: il évalue le chemin à temps minimal entre deux points. Il le fait sur la base d’un (ou plusieurs) modèles météo et dans un environnement relativement simplifié des cours d’eau. En particulier, l’ordinateur ne fait que peu d’évaluations des risques associés à la route calculée. Sur certains logiciels, on présentera des avertissements (vents violents, temps morts, etc.), mais ces logiciels sont très rarement interfacés avec des cartes marines officielles, encore moins avec d’éventuels avertissements à la navigation. Une vérification du trajet à l’égard des vents et des dangers environnant est de mise.

Il n’est d’ailleurs pas rare de voir les logiciels de traçage de route à temps minimal passer à des distances arbitrairement proches des côtes, sans évaluer les risques associés, et où les modèles météo seront beaucoup moins fiables. Dans le sentier à temps minimal (hypothétique) ci-dessous, une sérieuse évaluation du risque d’un passage serré le long de la côte serait de mise.

Application

Une composante importante servant à utiliser les applications de routage météo fut délibérément laissée de côté dans les sections précédentes: les courbes polaires de vitesse. Pour être en mesure de calculer le temps que prend un voilier entre deux points, il faut bien sûr une vitesse estimée des vents, mais également une manière de convertir cette vitesse des vents en vitesse de voilier à l’allure donnée.

Cette conversion est généralement faite par une courbe polaire d’un voilier (exemple ci-dessous), où chaque courbe représente la vitesse du voilier en fonction de l’angle au vent. Chaque courbe désigne une vitesse de vent. Sans cette courbe, impossible de calculer le temps passé sur un chemin intermédiaire!

Il va sans dire que la validité des résultats d’un trajectoire à temps minimal dépend également de la fiabilité de cette courbe. Les logiciels de routage demandent soit une courbe complète caractérisant le voilier (OpenCPN), soit quelques vitesses identifiées pour quelques allures (PredicWind). Ces informations existent à l’achat pour les voiliers modernes, mais les incitatifs économiques peuvent transformer ces courbes en pamphlets publicitaires pour montrer les « meilleurs conditions possibles ». C’est beaucoup mieux de faire sa propre évaluation empirique.

Lorsque c’est fait, l’application des logiciels de routage est relativement simple. ll suffit de sélectionner le point de départ, le point d’arrivée et les modèles météo sur lesquels on veut faire les calculs. Le calcul est alors soit effectué sur l’ordinateur d’où on travaille (OpenCPN), ou est transféré via le réseau sur les serveurs de l’application (PredictWind). Le deuxième cas signifie que les modèles météos à haute résolution n’ont pas à être téléchargés sur l’ordinateur de bord, une économie précieuse de bande passante (et de temps!) si on travaille avec un modem satellitaire (navigation hauturière).

Les modèles météos offriront généralement des trajectoires différentes quand les prévisions diffèrent. Les routes « fiables » dépendent donc de la fiabilité du modèle météo sous-jacent. On peut donc évaluer les chances qu’un modèle météo se réalise pour choisir sa route, ou encore pondérer les routes en fonction des risques implicites à chaque modèle. Dans un texte précédent, je soulignais l’importance d’une technique pratique visant à identifier les scénarios « win-win », soit les trajets qui fonctionnent bien en fonction de plus d’un scénario météo.

Conclusion

Les ordinateurs sont des instruments performants pour calculer rapidement des tonnes de données. Il faut cependant garder en tête qu’ils ne font rien de magique, raisonné ou réfléchi, mais n’obéissent qu’à quelques règles fournissant une réponse efficiente en vertu d’un seul critère (minimiser le temps). Il appartient aux personnes qui emploient ces résultats d’évaluer s’ils sont raisonnables à l’égard du contexte. Au premier chef, la sécurité de la route devrait être évaluée en fonction des informations disponibles à partir d’autres sources. Et bien sûr, rien ne dit non-plus que la route qui prend le moins de temps est la plus plaisante! Il faut donc penser à ses instruments comme des intrants à un éventuel plan de navigation plutôt qu’à une panacée. Vu qu’elles sont peu coûteuses, beaucoup plus rapides que l’humain à calculer différentes informations et font peu d’erreurs à produire les résultats pour lesquels elles ont été conçues, on serait cependant fou de s’en passer.

Ce texte vous a plu? Vous pouvez lire les autres se rapportant à la navigation.