Journal Alternative libre à MATLAB

Posté par (site web personnel, Mastodon) . Licence CC By‐SA.
33
7
oct.
2026

Sommaire

Avant-propos

Je ne suis pas un spécialiste de l'automatique, au mieux un amateur éclairé. J'ai eu besoin de mettre au point différents régulateurs pour des projets de contrôle moteur et je trouvais qu'il manquait d'exemples/retour d'expérience sur les alternatives à MATLAB (en français). C'est dans ce cadre que je vous propose cette synthèse subjective des solutions que j'ai testées.

L'article original est disponible ici

Intro

Dans cet article, je dresse un bilan de ma recherche de solution
alternative à matlab/simulink pour la simulation d'algorithme de contrôle/régulation.

Pourquoi simuler?
La mise au point d'asservissement ou de régulation comporte des risques. Il y a notamment un risque d'instabilité qui peut entraîner la destruction du système. Ce qui peut s'avérer coûteux et même parfois dangereux pour l'opérateur. Donc pour limiter les risques lors de la conception, on réalise sa mise au point via une simulation numérique.

Commençons par une petite mise en contexte. Si vous n'avez aucune idée de ce qu'est l'automatique, je vous laisse aller lire l'article wikipédia. C'est un vaste domaine qui couvre notamment, l'asservissement et la régulation de systèmes.

Un exemple: le fait d'attraper un objet avec ses doigts peut-être représenté comme un montage en asservissement. Le capteur est l'oeil, l'actionneur le bras et le cerveau le centre de calcul. La méthode classique pour documenter ce type de fonctionnement est de le représenter sous la forme d'un schéma fonctionnel:

Schéma fonctionnel de la prise d'un objet avec la main

Ce type de schéma permet de mettre en évidence les boucles de rétro-action ainsi que les différents éléments composant le système et leur interface avec le monde extérieur.

Pour prendre un autre exemple, plus concret, on va s'intéresser à la régulation en vitesse d'un moteur DC. Il servira aussi de référence tout au long de cet article. Son schéma fonctionnel est le suivant:

Schéma fonctionnel moteur DC

La simulation en automatique

Commençons par définir nos attentes quant aux solutions de simulation. Pour ma part, j'ai deux critères principaux:

  1. De bien simuler! Là c'est le rôle du solveur. Ce n'est pas vraiment mon domaine alors je ne rentre pas dans les détails
  2. D'être lisible. Comme on l'a dit en introduction, en automatique beaucoup de choses sont représentées sous la forme de schéma fonctionnel. Donc il est nécessaire de pouvoir rapidement faire la correspondance entre le code et le schéma

On pourrait aussi citer la rapidité, l'observabilité ou encore la facilité d'itération/modification, mais tous ces points sont plus ou moins liés au solveur et son interface.

Pour effectuer une comparaison des différentes solutions, on va se baser sur notre exemple d'asservissement et régulation en vitesse d'un moteur DC. Un cas d'application concret pourrait être le pilotage du moteur de brosse d'un aspirateur sans fil.

On représente ce pilotage par le schéma suivant:

Schéma fonctionnel moteur DC

On définit la fonction de transfert du moteur dans le domaine de Laplace tel que:

Avec:
- I: le courant traversant le moteur (A)
- U: la tension aux bornes du moteur (V)
- Ke: la force électromotrice (V/rad/s)
- Ohmega_m: la vitesse de l'arbre du moteur (rpm)
- L: l'inductance du moteur (H)
- R: la résistance du moteur (Ohm)

Avec:
- Kt: la constante de couple (N.m/A)

Avec:
- Cem: le couple électromagnétique (N.m)
- J: le moment d'inertie (kg.m2)
- Kf: les frottements visqueux (N.m.s)

On en profite pour définir aussi la fonction de transfert du régulateur PID:

Je ne rentre pas dans les détails de ces fonctions de transferts, ni même sur ce qu'est une fonction de transfert. Dans notre cas, on peut la considérer comme le modèle virtuel de notre moteur. En les intégrant au schéma fonctionnel précédent on obtient le schéma suivant:

Schéma fonctionnel détaillé moteur DC

Maintenant que nous avons défini notre exemple, nous allons implémenter ce système avec différents outils et en comparer l'utilisation. Vu que le logiciel MATLAB/simulink est la référence dans le domaine, on va commencer par lui.

Commençons par quelques définitions.

  • MATLAB c'est le nom d'un langage de script, mais aussi celui de son environnement de développement. MATLAB a été conçu pour manipuler des matrices et afficher des courbes
  • Simulink est un logiciel de modélisation de système dynamique reposant sur MATLAB. Il permet de créer des programmes sous la forme de schéma/ blocs

Pour schématiser grossièrement, MATLAB est le moteur et simulink l'interface utilisateur.

Maintenant que les présentations sont faites, passons à la mise en place de notre exemple. MATLAB n'étant pas un logiciel libre, une licence est requise pour son utilisation. Heureusement pour moi, l'éditeur propose une offre découverte gratuite à utiliser via une interface web (utilisation limitée à 20h/mois). Donc on ouvre MATLAB, on lance simulink et on rentre l'équivalent schéma fonctionnel précédent, ce qui nous donne:

Régulation moteur avec simulink

L'annotation en rouge est un ajout de ma part. Mais on remarque tout de suite l'un des points forts de simulink, son interface permet de faire un programme ayant une mise en forme proche du diagramme fonctionnel.

Un exemple de résultat de simulation, en jaune la consigne de vitesse et en bleu la vitesse du moteur. On peut visualiser ces valeurs grâce à la sonde nommée "Visualisation" sur notre schéma.

Résultas simulation

Remarque
Dans notre capture d'écran, l'on peut voir que nous avons utilisé des variables (kt, L, R...) dans les blocs que fonction de transfert. Un des inconvénients de MATLAB est que ces variables ne peuvent pas être facilement définies dans simulink. Le plus simple étant de créer un "workspace" dans MATLAB dans lequel on définit et assigne nos variables. Il faudra simplement penser à activer ce workspace avant de lancer notre simulation à la prochaine ouverture de MATLAB.
MATLAB workspace

Scilab/xcos

Lorsque l'on cherche une alternative open source à MATLAB/simulink Scilab est LA solution évidente. En effet, ces deux solutions ont une interface utilisateur très proche ainsi qu'un langage de script assez similaire. Puisqu'une image vaut mille mots l'implémentation de notre exemple via scilab/xcos sera sans doute plus parlant:

Régulation moteur avec Xcos

La ressemblance avec simulink est frappante même si à l'utilisation les deux interfaces ne sont pas strictement identiques. Un avantage qu'offre xcos, est d'intégrer la gestion du contexte (les variables comme Ke, L ou R) directement dans le fichier de schéma-blocs. Pas besoin de créer de workspace comme sous MATLAB.

Cette solution est donc parfaitement viable. Cependant, xcos souffre d'un bug particulièrement pénible: l'instabilité des liaisons entre les blocs. Il n'est pas rare de rouvrir un projet de découvrir qu'une ou plusieurs liaisons ne suivent plus le routage original mais ont été remplacés par une liaison directe entre les points d'encrage. Ceci rend le schéma nettement moins lisible, nous obligeant à refaire les liaisons lorsque ça arrive...

bug xcos

Une autre limite de cette solution, par rapport à MATLAB, est la petitesse de sa bibliothèque de blocs comparée aux bibliothèques disponibles sur simulink. Mais tous ces défauts ne sont pas immuables et seront sans doute corrigés à l'avenir.

Python/Jupyter

Avec cet outil, je vous propose une autre approche, plutôt que d'écrire un programme par schéma-bloque afin qu'il ressemble au schéma fonctionnel de la documentation, nous allons intégrer le code dans la documentation. Ou la documentation dans le code c'est vous qui voyez!

Cette alternative repose sur un ensemble de logiciels dont les principaux sont:

  • python le langage de programmation
  • Jupyter l'interface graphique
  • control, numpy et mathplotlib les bibliothèques scientifiques permettant de résoudre les équations, manipuler et afficher les données

Présentation

Comme je le disais en introduction, le principe de cette solution est de mélanger documentation et code. Pour être honnête, c'est le principe même de Jupyter, mais on va voir comment l'appliquer dans notre cas.
On va donc enchaîner les parties documentations au format markdown et le code en python (on peut d'ailleurs utiliser d'autres langages, mais je n'ai pas étudié cette possibilité).

Présentation

Dans cet exemple, on commence par un petit texte permettant de contextualiser le projet (1). On enchaîne ensuite avec l'importation des bibliothèques python nécessaires au projet (2). S'ensuit des explications plus précises quant au projet et le schéma fonctionnel permettant de le représenter (3). Enfin on termine la mise en contexte par la définition des différentes variables (4).

Modélisation du moteur DC

Cette approche a un gros inconvénient, elle est bien moins intuitive que la programmation par blocs. Cependant, elle offre d'autres avantages, comme une plus grande évolutivité et une plus grande souplesse dans la conception.
Elle permet aussi de tester/valider des sous-ensembles sans devoir refaire le programme.

Par exemple, plutôt que d'écrire le code pour l'ensemble de la simulation, on peut commencer par faire super bloc moteur qui inclut ses différents composants:

Super-bloc moteur

On remarque tout de suite que la courbe d'apprentissage de la bibliothèque control est plus raide que celle de simulink ou xcos. En particulier lorsqu'il s'agit de connecter les blocs entre eux (fonction ct.interconnect(...)).

Mais une fois cette difficulté surmontée, nous disposons maintenant un composant moteur ayant pour entrées U et Cr et pour sortie vitesse et que nous pouvons réutiliser à notre guise.

On peut donc facilement valider le comportement du moteur en boucle ouverte lorsqu'on le soumet à un échelon de tension de 10V:

Moteur DC en boucle ouverte

Pour faire cet essai dans simulink ou xcos nous aurions dû créer un nouveau projet et y intégrer les blocs moteur, la commande de tension et une sonde de mesure et ensuite alterner entre les projets en fonction des modifications/validations à réaliser.

Cette modularité est donc très appréciable. Pour aller plus loin, on pourrait créer un fichier python séparé dans lequel on placerait notre composant moteur. Ainsi nous pourrions facilement le réutiliser dans différents projets.

Modélisation du régulateur

On peut maintenant passer au bloc du régulateur PID, enfin dans notre cas c'est seulement un PI, le terme dérivé étant nul.

Bloc de régulation PI

Simulation complète

Nous avons maintenant tous les sous-ensembles nécessaires à la simulation de la régulation en vitesse du moteur DC. On commence donc par faire un rappel du système avec un schéma fonctionnel sans détails (1). Puis, on passe à la connexion des blocs et des entrées/sorties en python (2).

Régulation moteur

Enfin on peut afficher la réponse à un échelon de notre système. Dans notre exemple nous allons observer le comportement du moteur+asservissement pour une commande de vitesse de 1000 tr/min avec un couple résistant à zéro. Notre simulation durera une seconde avec un pas de temps 100 μs.

Réponse du système

Ce notebook est disponible sur codeberg.

Bilan

Après avoir testé trois solutions différentes pour faire de l'automatique, quel est le bilan ?

  • MATLAB/Simulink
    • Avantages:
      • Standard de l'industrie
      • Programmation graphique proche du schéma fonctionnel
      • Large bibliothèque de composants
      • Nombreux exemples disponibles
    • Inconvénients:
      • Non open source
      • Nouveau langage à apprendre (MATLAB)
      • format fichier peu adapté au versionnage (simulink)
  • Scilab/Xcos
    • Avantages:
      • Open Source
      • Programmation graphique proche du schéma fonctionnel
    • Inconvénients:
      • Nouveau langage à apprendre
      • versionnage
      • Bugs sur les liens (xcos) pénibles
  • Jupyter/control
    • Avantages:
      • langage python
      • Modularité, on peut facilement faire ses bibliothèques de composants
      • Open source
      • simple fichier texte, facile à versionner
    • Inconvénients:
      • Courbe d'apprentissage plus raide
      • Moins visuel, relecture plus difficile
      • Communauté plus petite, donc moins de ressources

Avec cet article, je souhaitais partager mon expérience sur la recherche d'une solution open source pour l'automatique. Il y a évidemment l'incontournable Scilab/Xcos mais pas seulement. Pour les personnes qui, comme moi, sont plus à l'aise avec du texte qu'avec une interface graphique, d'autres solutions existent. Ici par exemple, on arrive en combinant l'éditeur Jupyter et quelques bibliothèques python, à avoir une solution offrant documentation et calculs.

Cette solution n'est pas sans inconvénients, notamment l'intégration de matplotlib dans jupyter qui n'est pas trivial... Mais elle offre aussi de nombreux avantages. Comme la facilité de créer des bibliothèques de composants, versionner efficacement le code et la documentation ...

Pour ce qui est du versionnage, le code des bibliothèques est en python, la question ne se pose même pas et la partie notebook quant à elle est un fichier JSON, donc du texte. Cette solution vous permettra donc de gérer finement le versionnage de vos projets.

Autres pistes

Il existe encore d'autres solutions aux trois que j'ai étudiées ici, j'en ai trouvé une qui me convient alors je ne me suis pas attardé dessus mais si vous êtes intéressé voici une liste de celle que j'ai trouvées:

Il existe certainement encore d'autres solutions que je ne connais pas...

  • # Non utilisateur

    Posté par (site web personnel) . Évalué à 4 (+2/-0).

    Je n'utilise aucun de ces outils... Dans mon boulot, c’est plutôt LabView qui est utilisé pour piloter les manips (pas toujours, mais souvent). Cependant, je n'ai jamais codé et lancé LabView à mon niveau.

    Un critère qui me semble important est la Stabilité (Pérennité, Rétro-compatibilité...).

    Du peu que j’ai vu, on n’a pas envie de refaire tous les ans !

    Personnellement, j’ai des doutes que Scilab décolle réellement un jour et Python (et ses modules) cassent trop souvent ses API. J'en ai encore fait les frais sur de la CI avec Gitlab avant l'été.

    • [^] # Re: Non utilisateur

      Posté par (site web personnel, Mastodon) . Évalué à 1 (+0/-0).

      En effet, c'est quelque chose de pénible.

      Personnellement, pour python, j'essaie de gérer ça en limitant les dépendances et en ayant une copie local du dépôt (je n'y arrive pas toujours d'ailleurs).
      Python propose aussi un système de "cache" pour gérer les dépendances mais je n'ai pas encore eu le temps de regarder de ce côté...

    • [^] # Re: Non utilisateur

      Posté par . Évalué à 5 (+4/-0).

      Python (et ses modules) cassent trop souvent ses API

      Je te conseille fortement d'utiliser uv : c'est un gestionnaire de dépendances qui stocke dans un fichier la version de python et des dépendances du projet, et on peut donc utiliser un projet 6 mois plus tard avec exactement les mêmes versions (y compris les dépendances transitives).

      • [^] # Re: Non utilisateur

        Posté par (site web personnel) . Évalué à 5 (+3/-0).

        C'est souvent la réponse donnée. Refaire une installation avec les mêmes versions... Mais franchement, ce n'est pas soutenable dans la durée. C'est un pis aller pour ne pas faire du rétrocompatible. Personnellement, je n'ai pas envie que ma CI se relance sur des versions de modules qui ont 5 ans ou 10 ans d'âge.

        Heureusement que le noyau Linux et la libc sont rétro-compatible. À chaque fois que l'API est cassée, c'est très pénible pour tout le monde.

        Certains écosystème ne veulent pas l'entendre.

        • [^] # Re: Non utilisateur

          Posté par . Évalué à 2 (+1/-0). Dernière modification le 09 octobre 2026 à 11:37.

          Personnellement, je n'ai pas envie que ma CI se relance sur des versions de modules qui ont 5 ans ou 10 ans d'âge.

          Rien ne t'empêche de mettre à jour les dépendances régulièrement avec uv. Dans ce cas l'avantage c'est que tu fais les mises à jour quand tu le souhaites, pas quand tu dois faire une évolution en urgence et qu'une dépendance à cassé.

          • [^] # Re: Non utilisateur

            Posté par . Évalué à 1 (+0/-0).

            Je dirais même plus que c'est important de pouvoir réinstaller l'environnement à l'identique pour tester la non régression le mieux possible (surtout si tu n'a pas écrit tes tests)

            Dans mon domaine, c'est pixi/conda/docker/apptainer (guix pour les plus taquins) pour garantir qu'un programme s'installe et fonctionne partout (pratiques FAIR)

            L'évolution des dépendances, ça rentre dans le cycle de maintenance des logiciels (et si vous trouvez déjà ça pénible en python, ne faites pas de dev web)

            • [^] # Re: Non utilisateur

              Posté par (site web personnel) . Évalué à 4 (+2/-0).

              De mémoire je faisais du Sphinx avec Material. Je me fiche de la reproductibilité bit à bit dans 99% des cas, en plus, quand je change de machine, je change de CPU donc le résultat n'est pas toujours le même (à la décimale près).

              En science, on souhaite qu'un résultat soit reproductible ... à epsilon près, dans la très grande majorité des cas.

              Bon, quand je fait de la CI, je vais prendre par exemple une Debian stable -> trixie en ce moment. Mais à chaque fois, ma Debian stable à les dernières mises à jour de sécurité et tout n'est pas cassé.

              Ben ça, c'est hyper dur de l'avoir dans l'écosystème Python. Soit tu as tout pareil au numéro exact, sans correction de sécurité, soit c'est au petit bonheur la chance (heureusement, cela se passe quand même souvent bien).

              Alors oui, les tests aident. Mais quand même, c'est dans l'esprit que je trouve qu'il manque quelque chose.

              Imagine si le W3C changeait les choses sans phases de transition hyper longue ?

  • # PathSim et PathView

    Posté par . Évalué à 1 (+1/-1). Dernière modification le 07 octobre 2026 à 17:26.

    Je viens de demander à ChatGPT quelles alternatives à Simulink et il m'a indiqué en plus de celles que tu as données : PathSim (framework) et PathView (visualiseur) en Python.

    Ça a l'air récent et je ne sais pas ce que ça vaut...

    Eh oui, MathWorks (l'éditeur de MATLAB / Simulink) c'est la machine à cash, ils ne vous font pas de cadeaux !

    • [^] # Re: PathSim et PathView

      Posté par (Mastodon) . Évalué à 7 (+5/-0).

      Eh oui, MathWorks (l'éditeur de MATLAB / Simulink) c'est la machine à cash, ils ne vous font pas de cadeaux !

      Alors déjà je ne suis pas d'accord, j'ai eu des cadeaux chaque années où j'y ai travaillé.

      Et plus sérieusement j'ai vu bien pire ailleurs. Alors oui, il ne font pas de cadeau dans le sens où quand un acheteur les contacte pour demander une ristourne, la réponse est non. L'avantage au moins c'est que c'est pas un prix avec une ristourne à la tête du client. Par contre j'ai vu des pratiques commerciales bien pire d'autres éditeurs logiciels.

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: PathSim et PathView

        Posté par . Évalué à 5 (+4/-0).

        Je me souviens dans les années 2000, ils avaient une commerciale très sympathique, mais à part ça...

        Dans mon entreprise, MATLAB est partout avec tous types de licences (locations, flottantes, personnelles, avec ou sans maintenance, etc., des centaines de licences, sous Windows mais aussi sous Linux).

        MATLAB lui même n'est pas si cher, mais je suis choqué de voir les prix pratiqués par MathWorks pour le moindre toolbox et l'absence de tout geste commercial même vis à vis de très gros clients comme nous... Ils profitent allègrement de leur position de quasi monopole.

        Mais les choses sont en train de changer : de plus en plus, nous passons à Python, très progressivement car c'est difficile à cause de l'énorme existant sous MATLAB. Il n'y a pas de traducteur MATLAB => Python même si l'IA se débrouille pas mal. Ça reste un boulot énorme...

        Pour Simulink, le passage à Python est problématique en effet, mais Simulink n'est pas tant utilisé chez nous en raison du coût probablement... On peut faire la même chose sous MATLAB, en moins visuel bien sûr.

        Sinon Octave est une très bonne alternative à MATLAB, souvent compatible sans changer une ligne de code (et on peut utiliser les MEX fonctions comme sous MATLAB en changeant juste l'interface). Mais le gros point noir c'est la rapidité : Octave ne possède pas de compilateur à la volée (le JIT de MATLAB) et dès que le code nécessite des boucles (inévitables dès qu'on fait des analyses paramétriques, type variation du rapport signal à bruit) les temps de calcul deviennent quasi prohibitifs... Python se débrouille bien mieux (notamment en utilisant Numba ou Cython). Et Octave n'a pas d'alternative à Simulink non plus.

    • [^] # Re: PathSim et PathView

      Posté par . Évalué à 4 (+3/-1).

      MathWorks (l'éditeur de MATLAB / Simulink) c'est la machine à cash

      Petite anecdote rigolote à ce propos. Il y a très longtemps, cette boîte sponsorisait une école-chercheurs de chimiométrie, en marge de laquelle des doctorant·e·s présentaient leurs résultats notamment sous forme d’affiche.

      Un prix était attribué aux meilleurs posters, et la récompense, offerte par le sponsor, était une license individuelle MATLAB : pas mal, direz-vous, sauf que c’était seulement valable pour... l’avant-dernière version, alors même que le représentant de la boîte avait auparavant eu droit à un créneau de présentation pour faire l’article de la dernière version.

      Ce niveau de mesquinerie en avait épaté plus d’un·e.

  • # Ancien MathWorker...

    Posté par (Mastodon) . Évalué à 10 (+9/-0). Dernière modification le 07 octobre 2026 à 22:21.

    J'ai travaillé pendant des années avec Simulink (comme client de MathWorks, puis aussi chez MathWorks directement) donc je suis obligé de répondre, mais je suis surement biaisé.

    Un des inconvénients de MATLAB est que ces variables ne peuvent pas être facilement définies dans simulink

    On peut assez facilement (enfin, j'imagine que c'est peut être ça qui est discutable ?) créer une variable dans simulink, et qui sera sauvegardée avec le modèle, voire dans le fichier du modèle lui-même. Depuis toujours depuis le Model Explorer (l'outil au pire raccourcis claviers du monde :-D ), mais depuis quelque années normalement directement dans la fenêtre où on entre le paramètre :

    Par exemple, la valeur d'un gain. Tu mets un bloc gain, puis tu vas dans ses paramètres, tu rentres "un_tres_bon_nom_de_variable" dans le champ, et si ce nom n'existe pas il te propose de le créer. Tu choisis de le créer dans le workspace du modèle ou un dictionnaire de donnée, et c'est bon.

    Simulink est un logiciel de modélisation de système dynamique reposant sur MATLAB

    Alors, oui, si "reposant" veut dire que le bouton pour lancer Simulink est dans MATLAB, ou que tout ce qu'on utilise pour automatiser Simulink est dans/en MATLAB. Mais en vrai, le coeur de simulation (et à peu près tout sauf l'interface) c'est du C++ et du C. Et l'interface c'est du html/css/javascript (en tout cas maintenant ça devrait n'être plus que ça, je n'y suis plus pour vérifier qu'ils ont fini :-) )

    [Simulink] permet de créer des programmes sous la forme de schéma/ blocs

    Je trouve ça un peut réducteur.

    Alors oui, mais surtout il permet de les simuler, de simuler en faisant varier les paramètres. Il permet de simuler des système discrets, continus ou hybrides.

    Il permet aussi potentiellement de générer directement le contrôlleur qu'on a mis au point en C ou C++ et d'embarquer ce contrôlleur sur sa cible embarquée directement.

    C'est parce qu'il permet de faire plein de choses que la recherche d'une alternative est compliquée. Je pense qu'il n'existe pas une alternative qui fait tout, du coup certaines personnes vont dire "X peut remplacer Simulink", mais qu'un autre utilisateur de Simulink va se dire "n'importe quoi, ça ne fait même pas 10% de ce que je fais avec".

    Dans les alternatives que tu as cité en plus (et avec mes connaissances anciennes du sujet), OpenModelica est plus une alternative à SimScape (qui est un outil à l'intérieur de Simulink), octave et julia sont plutôt des alternatives à MATLAB.

    Après des gens font de la simulation robotique avec des outils issus du monde de ROS, c'est une alternative potentielle à Simulink sur ce domaine là. (et moi je fais de la robotique avec des outils maison, donc j'imagine que les outils maison, c'est une alternative aussi)

    J'ai plein de noms d'alternatives sur des petits morceaux de Simulink, mais c'est surtout des logiciels non libres :-D (et souvent c'était pas aussi bien...)

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Ancien MathWorker...

      Posté par (site web personnel, Mastodon) . Évalué à 5 (+4/-0).

      Merci pour ce retour riche en explications :D
      Je vais mettre à jour mon article avec vos informations.

      En effet, ma comparaison se limite à la partie simulation, ce qui ne représente qu'une partie des possibilité de matlab/simulink.

      Un autre "bon point" pour Mathworks par rapports à de nombreux autres éditeurs de logiciel métier: ils proposent une version linux.

  • # Octave

    Posté par (site web personnel) . Évalué à 10 (+9/-0).

    Alors, ça doit faire 20 ans que je n'y ai pas touché mais pendant mes études on utilisait matlab. En libriste convaincu, j'utilisais octave personnellement, et j'en étais très content.

    De ce qu'on m'a dit, octave + modelica est un excellent remplaçant à matlab + simulink. Pas exactement dans le même esprit, mais d'après certains retour plus puissant et plus flexible sur le long terme, même si un peu moins "user-friendly".

    Donc à essayer plus en profondeur peut-être ?

    • [^] # Re: Octave

      Posté par (site web personnel) . Évalué à 4 (+2/-0).

      J'ai fais pareil, il y a une disaine d'années. Je n'ai pas eu de problèmes majeurs.

      0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0

  • # utilisation de simulink

    Posté par . Évalué à 3 (+2/-0).

    pour ceux qui ne le savent pas encore simulink est très utilisé dans l’éducation national et fait partie des épreuves pour certain capes comme physique, électrique, mécanique.

    ca pique un peu lorsque vous arrivez la fleurs au fusils à l’épreuve :)
    et ce n'est pas donnée si vous comptez l'avoir chez vous pour vous entrainer.

    • [^] # Re: utilisation de simulink

      Posté par (site web personnel) . Évalué à 6 (+4/-0).

      de l'intérêt d'avoir des projets comme ClefAgreg pour promouvoir les logiciels libres directement utilisables.

      Je ne sais pas où ça en est :/

      on a aussi eu CAELinux à une époque pour des logiciels d'ingénierie (Salome, code_aster...) mais bon ce serait pas mal que cela perdure dans le temps (même si les logiciels sont installables sur à peu près toute distribution, avec plus ou moins de facilité on va dire pour certains logiciels...).

      • [^] # Re: utilisation de simulink

        Posté par . Évalué à 1 (+0/-0).

        Je suis d'accord sur le fait qu'utiliser un logiciel privateur dans la formation, c'est créer une dépendance à ce logiciel.

        Mais il faut être pragmatique, parfois, tu n'as pas le choix; les alternatives peuvent ne pas être (encore) abouties, et/ou c'est un logiciel métier très utilisé, et ne pas l'enseigner (aux profs et indirectement à leurs futurs élèves) sera problématique (il suffit de regarder les filières techniques orientées compta/gestion où les élèves doivent maîtriser des logiciels de compta qui dont plutôt privateurs).

        • [^] # Re: utilisation de simulink

          Posté par (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 10 octobre 2026 à 20:25.

          Mais il faut être pragmatique

          c'est assez faux, selon le type d'étude suivi...
          En modélisation 3D on avait Euclid (disparu), Autocad orienté 2D à l'époque qui a bien évolué depuis, puis bon stait déjà des vieilles versions, une fois sorti yavait eu 3 versions disponibles, à l'interface changée (forcément... mais heureusement quelques fonctionnalités supplémentaires), pas de Catia (faut pas déconner) même si on avait eu une démo iirc.
          Donc bon, il est plus pérenne d'apprendre les techniques/principes que le logiciel lui-même. Sinon, t'as investi tes études sur un truc obsolète, dépassé quand tu es diplômé.

          Bref quand j'ai dû réutiliser cela, BRL-CAD ou FreeCAD ça ne change rien, bin tu te paluches les tutos et tu commences par retrouver tes marques et de toute façon ces logiciels sont si complexes qu'il y a un type d'utilisation et des pratiques différentes selon le domaine...

          Même en compta, ce n'est pas tant le logiciel qui compte (! :p), c'est déjà comprendre à quoi servent un compte fournisseur, des opérations diverses, et la répartitions des imputations (bref, l'utilisation d'un plan comptable, sachant que cela aussi ça évolue :p)

  • # R!

    Posté par (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

    Je me dis que si on va du côté de « Python (au fait il manque le "h" si la modération passe par là) + Jupyter + control + numpy et mathplotlib (il semble qu’un saut de ligne en trop s’est glissé là si la modération passe par là) » alors on peut effectivement regarder aussi du côté de Julia (déjà mentionné, avec Pluto ou Marimo ou Neptune etc. que je n’ai jamais testé) ou de l’excellent R ...avec RMarkDown/RStudio (pour des documents interactifs/dynamiques comme Jupyter) ou mieux Quatro (mieux car a la notion de projet, et s’interface aussi avec Python et Julia), et control ou autres modules bien choisis (les équivalents de numpy et mathplotlib étant déjà intégrés vu la nature de R...)

    "It is seldom that liberty of any kind is lost all at once." ― David Hume

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.