Peu sont ceux qui travaillent sur le gain de temps en création logicielle. Pourtant, le Libre, ainsi que comme le développement rapide, permettent d’économiser le temps de travail, base de notre économie.
Le langage de modélisation unifié UML avait été créé pour le développement rapide d’applications. Les composants y sont modélisés sous forme de vues, de diagrammes et de modèles d’éléments. Mais UML n’est pas le seul outil dans ce domaine, UML vise plutôt l’analyse et la conception d’un système d’information, tandis que BPMN (Business Process Model and Notation) vise la conception des processus métier qui font intervenir et interagir des systèmes (c’est une norme ISO depuis 2013).
Matthieu Giroux est le concepteur d’un framework BPMN nommé Extended Man/XML Frames et est à la recherche de contributeurs. Extended Man/XML Frames est un cadriciel de Développement Très Rapide d’Application (DTRA), c’est un projet libre couvert par la licence GPL et disponible sous Windows et GNU/Linux (et possiblement macOS).
Sommaire
- Introduction
- Quand Delphi régnait sur le RAD
- Le framework Extended
- Une histoire de licences
- Publication, conférence
- Lazarus : vers de nouveaux horizons
- Des routes et des ponts
- En quête de contributeurs
N. D. L. R. : Matthieu Giroux nous a proposé un journal puis une dépêche qui nous ont paru intéressants. Le journal (et la dépêche initialement soumise) se révélant difficile d’accès pour des personnes ne travaillant pas dans le domaine, plusieurs contributeurs se sont proposés pour retranscrire son témoignage. Cette dépêche reprend donc les éléments donnés par Matthieu dans son journal et dans sa dépêche initiale, en tentant de la rendre accessible à tous et a été complétée sur la base d’une interview de l’auteur par _papap. N’hésitez pas, vous aussi, à participer à l’espace de rédaction collaboratif de LinuxFr.org ! ;-)_
Introduction
Pour essayer de rassurer les développeurs qui pourraient craindre de perdre leur travail à cause du développement rapide ou très rapide d’application, Matthieu Giroux est convaincu que lorsque l’on pourra créer rapidement des applications, les programmeurs pourront devenir chercheurs, pensée qu’il a développée dans son essai Du geek au génie. Contrairement à programmeur, chercheur sera un métier qu’un robot ne pourra enlever à l’homme.
Quand Delphi régnait sur le RAD
Delphi a été développé en 1995 par Borland comme un outil de développement rapide d’application (RAD) pour Windows.
Extrait de Wikipédia :
À la fin des années 1990, Microsoft débauche une grande partie de l’équipe initiale ayant conçu Delphi, dont Anders Hejlsberg (le créateur de Turbo Pascal). Anders Hejlsberg travaillera d’abord sur la bibliothèque de classes du langage Visual J++, puis sur le projet .NET et sera l’inventeur du C#. Le départ de nombreux membres coïncide avec une baisse générale de la qualité du produit, ainsi qu’un manque d’investissement marketing de la part de Borland, menant à un déclin progressif de Delphi.
Une première tentative de créer un clone libre de Delphi appelée Megido a eu lieu en 1998 mais tourna court, et Lazarus Free Pascal fût créé en février 1999 pour sauver ce qui restait de Delphi. Ce fut un rebond salutaire puisque Lazarus a été élu projet du mois sur Sourceforge.net en août 2017, ce qui témoigne à la fois de la durabilité du projet et de son succès.
Avec son cadriciel de développement très rapide d’application Extended Man/XML Frames, Matthieu Giroux se place en pionnier de l’automatisation de création logicielle. La démarche de réalisation de logiciel MDA (Architecture dirigée par les modèles) existait déjà, mais Matthieu considérait que créer des logiciels en copié‐collé n’avait pas de sens, c’est pourquoi son cadriciel fut créé bien avant que ne se démocratise la pratique d’Ingénierie dirigée par les modèles.
Matthieu Giroux nous rapporte qu’entre 2003 et 2006 tandis qu’il travaillait chez Microcelt, son cadriciel développé au départ en Delphi, permettait de gagner trois fois plus de temps que ceux des autres entreprises. Cela avait alerté Cap Gemini qui côtoyait Microcelt sur un projet de PGI (Progiciel de gestion intégré) pour l’entreprise Le Duff.
Le framework Extended
En 2008, Matthieu Giroux publie son projet Extended sur un site peu connu. Il s’intéresse alors à ce qui se fait sur le marché et découvre le projet Léonardi GPL, un cadriciel de la société Lyria (rachetée en 2008 par W4). Matthieu porte donc son cadriciel sur Léonardi et crée XML Frames et Man Frames. Pour ne pas se perdre dans tous ces noms, il convient de noter que Léonardi devient W4 Express en décembre 2013 et la société qui le développe, W4, est reprise par Itesoft en 2015 pour 2 à 4 millions d’euros.
W4 Express était libre à l’époque (et est à l’origine de nombreux clones), mais a été privatisé par la suite (probablement avec la version 9 en 2011). Le cadriciel de gestion de Matthieu devient alors Extended Man/XML Frames. XML Frames permet de créer un logiciel à partir des fichiers passifs (fichiers de description de ce que l’on veut) de W4 Express, tandis que Man Frames permet de créer un logiciel très rapidement sans nécessiter ces fichiers. L’ambition d’alors de Matthieu est de créer une partie Web et d’automatiser XML Frames.
L’interface Ext Pascal (qui connecte Pascal à JavaScript) permet de créer une application Web avec des Composants et une adaptation rapide du projet de Matthieu était donc possible. Cependant la partie Web ne fut jamais finalisée, car le projet fut abandonné en 2015 quand le dernier informaticien (bénévole) du projet Ext Pascal a été débauché par la concurrence, c’est‐à‐dire une entreprise travaillant sur Uni GUI (et qui payait).
Une histoire de licences
Début 2010, Matthieu obtient de Microcelt l’autorisation officielle de publier son travail sous forme libre à condition de redonner les sources à Microcelt. Il publie cette fois son code sur Google Code, sous licence GPL, pour que cela soit diffusé rapidement et pour imposer le repartage des sources. Mais cela freine les utilisations commerciales, d’où la décision de passer le code sous licence LGPL, qui permet la réutilisation sans partage des sources. Les téléchargements augmentent alors.
Pour essayer de valoriser son travail, Matthieu tente en 2014 la LGPL Sencha, qui oblige de payer pour avoir la licence permissive LGPL au lieu de la GPL. Mais personne ne paye. Matthieu revient alors à la GPL en septembre 2015. Alors qu’il recensait 200 téléchargements par mois, ce changement de licence provoque leur effondrement.
Publication, conférence
Constatant le manque de livre sur Lazarus, Matthieu en écrivit un, publié en 2009 et 2010 sous licences libres, livre dans lequel il traite de Lazarus et de son cadriciel Extended Man/XML Frames.
C’est aussi à cette époque, en mars 2010, qu’advient le Breizh Entropy Congress que nous avions annoncé dans nos colonnes. Matthieu Giroux y avait présenté le Développement Très Rapide d’Applications Libre lors d’une conférence intitulée Lazarus et développement très rapide en gestion, dont Matthieu n’a malheureusement pas pu se procurer l’enregistrement.
Lazarus : vers de nouveaux horizons
En sortant de Microcelt, Matthieu avait découvert que CEGID développait également un cadriciel Delphi, qui semblait moins bien réalisé que W4 Express, selon Matthieu, mais qui était aussi plus ancien. CEGID passera de Delphi à Visual Studio .Net se limitant de fait aux plates‐formes Windows, alors que Delphi permettait plus de portabilité et leur aurait permis d’être sur toutes les plates‐formes, excepté GNU/Linux (le rachat de CEGID par des fonds américains pourrait expliquer ces choix). De son côté, Matthieu porte son cadriciel sur Lazarus, le rendant également disponible sur GNU/Linux.
Matthieu prend conscience que, dans le contexte de Gestion des processus métiers (BPM), son cadriciel implémente la version BPMN+ de ce qui s’appelle le BPMN (modèle de procédé d’affaire et notation). Le BPMN est une spécification de modélisation qui vise l’analyse et la conception des processus métier.
Des routes et des ponts
On trouve dans cette histoire des similitudes avec ce que décrit Nadia Eghbal dans son livre Roads and Bridges, traduit par Framasoft en 2016 sous le titre Sur quoi reposent nos infrastructures numériques ?. En effet, des entreprises font de gros chiffres d’affaires et leurs logiciels se basent sur des briques de logiciels libres qui sont suivis par peu de personnes (Lazarus), voire plus personne du tout, comme Ext Pascal.
Un autre point est ennuyeux, c’est que de nombreuses entreprises du secteur téléchargent, utilisent et développent à partir du développement que Matthieu a publié sous licence libre sans toutefois ni créditer Matthieu, ni publier ou partager leur propre développement sous licence libre, comme la GPL l’exige.
En quête de contributeurs
Matthieu est donc à la recherche de contributeurs pour son cadriciel. Extended est un des plus anciens cadriciels de ce type en Pascal, et ce serait désormaisn selon Matthieu, le seul cadriciel BPMN 2 partagé dans ce langage.
Extended Man/XML Frames permet de créer des applications à partir de W4 Express, sur Windows, GNU/Linux, voire macOS 32 bits. La partie XML Frames est toujours en développement et Matthieu peut être contacté via son compte Bitbucket.
Aller plus loin
- Dépôt de sources sur Bitbucket (371 clics)
- Présentation du DTRA par Matthieu Giroux (634 clics)
- Sources Liberlog (217 clics)
- Essai : Du geek au génie (455 clics)
# cegid ?
Posté par btc . Évalué à 2.
Cegid a tout de même repris des solutions à droite à gauche et les vend à son nom depuis belle lurette
Ex : leur ERP Cegid manufacturing (PMI)
Avec initialement une base sur Firebird (maintenant firebird ou ms sqlserver), et le soft développé avec Windev.
[^] # Re: cegid ?
Posté par NumOpen . Évalué à 7.
Et à chaque fois qu'ils rachètent un logiciel de gestion, ils stoppent le renouvellement de licence du produit précédent, obligeant ainsi tous leurs clients à repasser à la caisse et à reperdre 1-2 ans d'intégration. À fuir en courant.
[^] # Re: cegid ?
Posté par Philippe M (site web personnel) . Évalué à 3.
C'est la méthode de beaucoup d'éditeur d'ERP (et d'autres surement), ils rachètent au lieu de créer. Plus facile, pas de R&D, plus d'argent car une nouvelle version que le marketing s'empresse de vendre au client de l'ancienne version.
Born to Kill EndUser !
[^] # Re: cegid ?
Posté par ord . Évalué à 5.
En faite c'est une pratique courante pour contrebalancer le fait que l'innovation est tres difficile dans une grosse boite a cause du poid de l'administration. Une solution est d'acheter des petites boites qui elles ont reussit a innover.
apres je ne suis pas capable de juger si la methode est etique ou pas. Elle est courante et connue.
[^] # Re: cegid ?
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Me semble faux. C'est un problème social du à la taille. Voila en schématisé ce que j'ai compris :
si tu innoves et que cela marche, les autres t'en voudront et donc tu n'auras pas de promo (en plus, les autres te diront que toi tu t'éclates dans le boulot et ne te fait pas chier comme eux).
si tu innoves et que cela ne marche pas, tu auras un échec sur le dos et donc tu n'auras pas de promo.
Bilan : tu suis comme un mouton et ne fais surtout pas de vague ;-)
[^] # Re: cegid ?
Posté par ord . Évalué à 2.
Tu as une vision tres negative da la culture des boites ;-)
Mais j'admet que c'etait une enorme simplification. Il y a beaucoups de parametres qui jouent comme par example la dilution de la responsabilite. Ca diminue les risque d'erreur mais auasiment persone n'a assez de pourvoir pour faire passer un choix difficile, allors on fait de la micro-navigation.
[^] # Re: cegid ?
Posté par damaki . Évalué à 2.
Dans les petites boîtes par lesquelles je suis passé, je te garanti que c'est aussi compliqué. On considère implicitement que l'innovation doit venir des commerciaux, de la MOA, des architectes où du pôle R&D (1 personne). Toute innovation venant du bas de la chaîne a tendance à être de base mal considérée, même si on s'applique à démontrer un impact business positif ou pire à démontrer l'impact négatif par rapport à la concurrence de ne pas le faire. Pire, l'innovation technique est mal vue dans des boîtes qui pourtant se vantent d'être à la pointe (IoT et compagnie) parce que c'est toujours trop cher.
# 200 téléchargement par jour ?
Posté par jtremesay (site web personnel) . Évalué à 2.
Dans le journal original, ça parle de 200 téléchargements par mois.
[^] # Re: 200 téléchargement par jour ?
Posté par ZeroHeure (site web personnel) . Évalué à 3.
corrigé, merci
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# .
Posté par guppy . Évalué à 6.
Pour ma part je suis très dubitatif sur ce genre de framework. Je trouve que ça a tendance à donner des logiciels qui ne sont que des suites de formulaires et de grilles.
Ca me fait d'ailleurs beaucoup penser aux produits PC Soft. Bien sûr, ces dernières ne sont pas libres, ni multiplateforme (enfin de manière embryonnaire à ma connaissance). Mais ils promettent grosso modo les mêmes choses :
* développement très rapide
* se concentrer sur le métier
* accessible à tous
Certes, ces points sont positifs. Faire disparaitre la partie technique c'est louable pour le client (même si 90% de la population d'ici deviendraient chômeurs ;) ). Mais un bon logiciel n'est pas qu'un logiciel qui respecte parfaitement la logique métier et qui n'a pas de bug. C'est aussi un logiciel qui est raisonnablement performant par exemple (pas de sensations de latence, les actions dans la mesure du possible devant durer moins d'une seconde par exemple). Et ça c'est purement technique. Ce type de framework est souvent très mal placé à ce niveau. Enfin c'est le cas de toutes les applications Windev que j'ai vu.
Et c'est normal parce que développer c'est choisir. Choisir par exemple un haut niveau d'abstraction (et donc en accepter les conséquences). Néanmoins avec ce genre de framework on ne choisit pas, on est coincé et c'est pour ça que je ne les aimes pas.
Ceci dit ça doit être très intéressant à développer, donc bon courage à toi.
[^] # Re: .
Posté par Wawet76 (site web personnel) . Évalué à 8.
Je n'ai pas été voir ce que propose le framework dont parle la dépêche.
Le besoin de pouvoir développer rapidement et simplement des applications qui sont juste "des suites
de formulaires et de grilles" existe vraiment. On trouve en entreprises des trucs parfois assez gros à base de MS Access ou Excel…
[^] # Re: .
Posté par Renault (site web personnel) . Évalué à 5.
Bof non, heureusement l'industrie du logiciel ne se concentre pas uniquement sur des applications type gestion de stock qui sont en effet bien gérés par ce genre d'outils.
Je ne me vois pas coder le site Web d'Amazon, de Google, Facebook, concevoir le logiciel d'une carte embarquée avec ce genre d'outils. Sans compter les applications bureautiques riches (genre Photoshop / GIMP, les suites Office, etc.). Bref, ces outils sont réservés à une fraction seulement des applications possibles.
# Allez, on se lance...
Posté par Dring . Évalué à 10.
Alors, pour ma part, tout ce qui tourne autour de UML : c'est de la merde. Les diagrammes peuvent être intéressants, mais dès lors qu'ils sont utilisés par un spécialiste ça tourne au cauchemar. La grammaire peut être assez sournoise et ce qui devait être un langage "universel" devient alors un nid à piège ("mais si regarde : le bout de la flèche est comme ça, donc c'est une relation qui se lit dans l'autre sens !"). Et au final, je préfère largement écrire une spécification en langage naturel…
Pareil pour la génération automatique de code avec cette horreur : ça ne tient jamais au delà de la génération initiale. Je n'ai jamais vu personne faire vivre un logiciel avec ça, et au final le code généré fait chier tout le monde.
Pour BPMN, je n'ai pas d'expérience directe, et j'attends vraiment de savoir comment ça se tiendra dans le temps. Mais le premier cas que j'ai pu voir, c'est jBPM+Drools, et ce que j'entends c'est : "tout est en drools, du coup c'est à la main du métier, et du coup c'est le gros merdier, personne ne comprends plus rien".
Bref, tous ces trucs me font très peur, et à part pour des petits trucs tout simples pour lesquels de toute manière n'importe qui peut sortir un truc en quelques jours, je n'ai rien vu qui ne parte pas en cacahuète.
[^] # Re: Allez, on se lance...
Posté par Pierre Jarillon (site web personnel) . Évalué à 9. Dernière modification le 25 octobre 2017 à 00:11.
Je confirme. Tous les générateurs de code et les générateurs automatiques de base de données pour les nuls, ça finit toujours en cacahuète…
Le problème, c'est que ça semble fonctionner parfaitement au début. Mais quand on veut modifier ou pire ajouter une fonction qui n'est pas prévue dans le système de base, c'est une galère épouvantable.
Je me souviens d'un logiciel générateur de code qui générait 100 000 lignes de code en COBOL alors que je faisais la même chose en Fortran écrit avec VI en quelques centaines de lignes. Il m'était assez facile de modifier tandis que mon collègue devait lire un épais listing et faire les modifications du code qui rendaient impossible de le gérer ensuite autrement qu'à la main.
J’avais essayé UML il y a presque 20 ans. Cela m'a autant inspiré que le cycle de développement en V responsable des plus gros échecs en informatique.
Il y a des raisons à cela :
* informatiser une tâche change le mode de travail de l'utilisateur donc rendent les spécifications obsolètes;
* on peut vérifier qu'un logiciel est conforme à ses spécifications mais il n'existe pas de méthode pour vérifier que les spécifications étaient conformes aux besoins;
* l'environnement et les conditions de travail évoluent;
* les spécifications sont faites par des personnes qui ne connaissent pas le métier ou croient le connaitre.
Alors quelles solutions ? Pour moi il faut avoir une double compétence en informatique et dans le métier. Lorsque l'utilisateur n'est pas l'informaticien, il faut deux personnes qui apprennent chacune le métier de l'autre. Cela évite de demander des choses complexes que l'on croyait simples mais peu utiles et de proposer des choses simples, vite réalisées mais très efficaces qu'un non informaticien n'oserait pas imaginer.
Je me suis toujours dit : cela me demande 10h de travail, ce sera rentabilisé en moins d'un an, donc c'est urgent. Si ça me demande 200h pour économiser 10h de travail par an aux utilisateurs de mon entreprise, ça peut attendre.
En bref je crois méthodes agiles et à l’efficacité.
[^] # Re: Allez, on se lance...
Posté par matthieu . Évalué à 1.
Le fait qu'un moteur VRAD présente mal une application BPMN, ça peut se résoudre avec les groupes. On parle alors de Design et Développement Très Rapide d'Applications.
Matthieu Giroux Rennes
[^] # Re: Allez, on se lance...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
(Pause historique)
Javais rencontré un AGL (Atelier de Génie Logiciel, ou CASE en anglais) dans les années 90, quand la mode des applications clients/serveur était en plein boum, qui était très riche (mais lourd), ambitieux (et donc complexe), et qui faisait ce qu’on lui demandait, c’est à dire qu’il permettait de concevoir puis de générer des applications de gestion et la base de données associée. Ça n’était pas libre du tout, car c’était un produit d’Oracle, Case Designer. À l’époque, on ne parlait pas encore d’UML, mais de Merise, et la méthode d’Oracle était très proche de Merise. Ça permettait de générer du Forms en C/S (ainsi que les autres composants d’Oracle Developer), puis du Forms en mode appliquette Java, puis du PL/SQL qui pouvait générer l’affichage de formulaires web, au fil des versions. Oracle l’utilisait lui-même pour générer Oracle Applications, son PGI qui voulait concurrencer SAP.
Le projet GNU ambitionnait de faire un équivalent libre, GNU Enterprise ou GNUe, qui générait du GNU Forms à partir de XML. Mais aujourd’hui j’ai l’impression qu’Oracle et GNU ont tous les deux abandonné ce créneau.
[^] # Re: Allez, on se lance...
Posté par matthieu . Évalué à 1.
Dans les faits les savoir-faire BPMN sont très privatifs. Il s'agit d'être suffisamment puissant pour créer une IA capable de créer du code.
Matthieu Giroux Rennes
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Le but d'UML, c'est de fournir un langage. Comme un langage de programmation, en fait. On pourrait donc écrire tout le comportement du logiciel en UML et donner ça à un compilateur qui en ferait un binaire.
L'avantage d'un langage comme UML, c'est qu'il est plus facile à lire que du code en C, par exemple. L'inconvénient, c'est qu'il est beaucoup plus compliqué à compiler et aussi peut-être trop subtil pour certaines choses.
Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.
Pour moi, la conclusion, c'est qu'on ne peut pas encore fusionner les spécifications et le code qui les implémente. L'un est lisible par les humains, l'autre par les ordinateurs. Et on ne parle pas encore la même langue.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
C'est toujours mieux que rien. Je lis beaucoup de gens ici se plaindre d'avoir à écrire du code boilerplate et franchement écrire le squelette d'une classe, ce n'est justement que ça.
Personnellement, j'ai travaillé il y a une quinzaine d'années sur un projet où la spécification détaillée a été écrite en utilisant des diagrammes de cas d'utilisation, des diagrammes de classes et des diagrammes de séquences.
Finalement, le client, un automaticien reconverti en chef de projet, a trouvé le document très clair et cherry on the cake, on utilisait le même modèle UML pour générer l'ossature du code C++ ainsi que remettre les diagrammes à jour depuis le code ensuite.
Alors, ce n'est pas parfait mais pour moi, le code n'est que la conséquence de la conception et la conception est l'image de la compréhension du problème. UML fournit un langage qui permet de représenter rapidement l'image qu'on se fait du problème.
Du coup, pPlonger dans le code directement introduit les biais issus de la conception du langage et obscurcit par la même occasion le problème.
Au passage, aux dernières nouvelles, le code C++ généré (en partie) fonctionne toujours.
[^] # Re: la spec, c'est le code
Posté par Wawet76 (site web personnel) . Évalué à 1.
On peut dire la même chose du diagramme UML…
En fait si le code peut être généré depuis l'ULM et inversement, il n'y a pas beaucoup de valeur ajoutée à faire l'un plutôt que l'autre. Je fais partie de ceux qui trouvent plus clair de définir le modèle de donnée directement en code plutôt qu'en UML.
Et si quelqu'un veut absolument de l'UML pour discuter, bah on le génère depuis le code. Y'a autant d'info au final, et c'est plus facile à maintenir dans ce sens là.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
C'est censé être un vue synthétique, pas exhaustive ce qui est impossible, le code lui le sera toujours, exhaustif.
Ce ne sont pas les mêmes niveaux de conception. D'ailleurs, le code, ce n'est pas de la conception, c'est de la réalisation.
C'est peut-être aussi pour ça qu'un architecte fait des plans de maison et que le maçon les réalise ensuite.
Au passage, j'adorerai voir une méthode agile appliquée au bâtiment :D
L'informatique me donne l'impression d'être la seule activité d'ingénierie qui dit, on fait sans concevoir parce que c'est chiant et qu'il est plus facile de refaire ce que l'on a réalisé.
Ben, y a des gens qui ne lisent pas le code et pour qui une représentation graphique vaut mieux qu'un long discours abscons dans une langue inconnue.
[^] # Re: la spec, c'est le code
Posté par Wawet76 (site web personnel) . Évalué à 2.
On leur génère leurs diagrammes UML à partir du code. C'est de la documentation.
Le seul point sur lequel on n'est pas d'accord, c'est que tu considère qu'on ne peut pas faire de la conception en codant.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
Exactement, tout comme on ne conçoit pas une maison pendant qu'on la construit.
Il y a quand même un bémol, si le projet est de taille raisonnable, c'est faisable mais dès que le projet devient gros et qu'il y a toute une équipe de développeurs, ça devient le bordel et chacun "conçoit" dans son coin.
Et de toutes façons, comme tu le dis, c'est de la documentation donc ce n'est pas inutile.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la spec, c'est le code
Posté par Selso (site web personnel) . Évalué à 1.
C'est bien pour cela que je vois plus l'UML comme un langage, avec des possibilités d'interprétation (une notion de sémantique), et l'appellation "langage" de notre code comme un abus car il s'agit plutôt d'une syntaxe sans équivoque.
On pourrait générer un code complet avec la notation UML, mais le générateur obéirait forcément à des règles de génération dont on devrait avoir conscience.
D'un autre côté je pense que tout spécifier graphiquement nuirait à la productivité.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
C'est pour ça que l'on parle de modèle d'analyse, de modèle de conception et de modèle d'implémentation. Le dernier n'est normalement qu'un extrait de l'implémentation réelle qui n'ont aucun intérêt dans une représentation graphique.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
C'est rigolo comme formule quand on pense que c'est dans le ferroviaire, l'aéronautique et le spatiale qu'on cherche le plus à faire du développement piloté par les modèles :D
Du coup, on écrit des spécifications au travers de modèles que l'on transpose ensuite dans le langage cible.
Pour le reste de l'informatique, tout ceci a pratiquement disparu et quand tu cherches une documentation technique de haut niveau, on te renvoie vers le code parce que c'est le code qui fait foi, ce qui est vrai au final mais terriblement bas niveau.
Finalement, c'est juste la mort de l'ingénierie logicielle sacrifiée à l'autel du Time to market
[^] # Re: la spec, c'est le code
Posté par Wawet76 (site web personnel) . Évalué à 6.
La méthodologie expliqué dans le livre "Domain Driven Design" est pas mal utilisé en dehors des secteurs que tu cite. Et au final c'est un truc centré sur le modèle de donnée.
Je ne vois pas en quoi du code est terriblement bas niveau.
Si c'est la mort de l'ingénierie logicielle qui considère que le code c'est pour les grouillots car c'est trop concret pour eux, et bien je ne vais pas les pleurer.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
Une conception peut être réalisée dans différents langages et ne spécifie pas les détails d'implémentation.
Je n'ai jamais dit ça mais pour comprendre un problème faut-il obligatoirement être un dieu du langage d'implémentation ?
C'est juste une séparation des responsabilités ou des niveaux d'abstraction.
D'ailleurs, dans le cadre du développement d'un système complet, il peut très bien y avoir différents langages d'implémentation. doit-on tous les connaître pour comprendre ce que fait le système dans son ensemble ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la spec, c'est le code
Posté par Renault (site web personnel) . Évalué à 8.
C'est sûr que quand tu travailles sur des projets simples, avec peu de conséquences, et peu d’interactions, se passer de la conception hors code c'est simple et confortable.
J'ai bossé sur des systèmes embarqués (sur des systèmes critiques ou non) et j'ai bien apprécié que le code ne soit pas la seule source de documentation :
Bref, le code c'est la documentation c'est valable pour un logiciel isolé avec une équipe composée uniquement de codeurs, capable de lire le code ou la documentation générée. Mais ce n'est pas systématique. Quand je code un logiciel qui communique avec celui de mon collègue, j'apprécie de ne pas avoir besoin de connaître en détail son architecture pour savoir ce que je peux lui envoyer et ce que je dois recevoir. Ce qui m'intéresse ce sont les entrées / sorties et c'est tout.
Et la conception, pour des logiciels non enfouis, il y a souvent un non technicien qui va intervenir dans la conception de l'UX par exemple. Son rôle n'est pas de déterminer depuis le code (ou sa documentation) comment ça va s'afficher, les options proposées et autres. Il a besoin de documents qui ne gèrent que cela.
Du coup un document texte et des diagrammes UML c'est utile pour que tout le monde communique sans exclure les non codeurs. Cela me paraît essentiel.
[^] # Re: la spec, c'est le code
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Dans le cas du spatial ou du ferroviaire , on peut tout spécifier, il n'y a pas ou que très peu d'exceptions.
Dans le cas d'un logiciel de gestion faisant intervenir des humains, le nombre de degrés de liberté devient énorme et les belles méthodes idéales atteignent vite leurs limites.
Le logiciel que j'avais fait gérait tous les cas même tordus. C'était l'individu qui décidait et la machine qui enregistrait ses décisions. J'ai mis des années à inclure les 400 règles du métier et cela a permis d'avoir les mêmes règles dans chaque établissement et chaque secteur. Les gains de temps ont été très importants et les utilisateurs avaient confiance dans un système conçu pour les aider. C'était plus rentable que de faire un système censé aider leur hiérarchie à faire des statistiques…
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Certes mais cela n'empêche pas d'avoir un minimum de documentations comme une spécification fonctionnelle, un modèle de base de données (en quoi d'ailleurs ? En SQL directement ou en Entité-Relation/Merise ?) et une spécification technique (explication "grosse maille" de l'architecture du code)
J'ai toujours trouvé que, pour les logiciels de gestion, le principal avantage de l'analyse, c'est de permettre de rationaliser les strates de process qui n'ont pas été dépoussiérées depuis des lustres par le client :)
[^] # Re: la spec, c'est le code
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui mais bon, on s'éloigne d'UML qui contient plusieurs centaines de concepts, c'est trop pour comprendre toutes les subtilités.
Pas forcément. La mode est de décrire l'architecture, tu as en gros 3 graph : le fonctionnelle (l'ensemble des fonctions de ton code + ou -), le logiciel (en gros les paquets autour des fonctions, qui dialogue avec un Os, et gère la redondance, et les paquets réseau), et le hardware (cpu+réseau).
Une fois que tu as tout ça, tu peux générer tous les stub C de communication pour chacun des ordinateurs de ton architecture (startup code, les différents channels et leur config). Tu peux faire les tables de routages des switch (AFDX). Tu peux faire ta configuration vxworks pour chaque instance de l'OS (du xml). Tu peux générer la doc d'interface (API, …). Et si tu change les entrées/sorties, tu régénères tout d'un clic.
Le contenu des fonctions n'est pas détaillé, et doit être remplit par du "code classique".
C'est une approche puissante, car tu peux jeter l'un des 3 graphs, si tu change de hardware, ou si le hardware est imposé, mais le logiciel est nouveau.
"La première sécurité est la liberté"
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Tout à fait d'accord. Personnellement, je trouve aussi qu'il y a trop de choses dans UML mais avec les diagrammes de classes, de séquences et use-cases, tu documentes déjà pas mal.
Après,un diagramme de déploiement ne fait pas de mal :D
Je ne voulais pas forcément parler d'AADL et autres joyeusetés, ça aurait filer trop de boutons à certains ;)
[^] # Re: la spec, c'est le code
Posté par mzf (site web personnel) . Évalué à 2.
Petite citation au passage, venant de Agile Principles Patterns and Practices de Robert C. Martin.
L'annexe B renvoie à la question "What is software?"
La suite de l'argumentaire est la comparaison entre l'ingénierie logicielle et l'ingénierie plus classique qui génère des biens matériels.
Dans l'ingénierie traditionnelle on prend les documents de conception et on construit l'objet, et dans l'informatique on fait exactement la même chose sauf que les documents de conception sont les fichiers sources !
C'est donc le compilateur qui construit le logiciel et la différence avec l'ingénierie de biens matériels c'est que le temps et le coût de génération sont très petits.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Ok, je te file un code en Ada83 de plusieurs dizaines de milliers de lignes et je te dis, voilà le doc de conception, tu as deux heures pour m'expliquer ce que tu as compris… Et encore, avec toi, j'ai bon espoir, tu fais du C++ :)
[^] # Re: la spec, c'est le code
Posté par Moonz . Évalué à 5.
Je te donne les plans d’architecte d’un aéroport et tu as deux heures pour m’expliquer ce que tu as compris.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Ça reste un diagramme alors sauf s'il est écrit des annotations en cyrillique, oui, j'ai l'espoir, voire la prétention, d'en comprendre nettement plus qu'un code écrit en Brainfuck par un obscur codeur qui a décidé qu'il ne documenterait rien car son code est, de fait, auto-documenté.
[^] # Re: la spec, c'est le code
Posté par Moonz . Évalué à 1.
Tu peux aussi faire des diagrammes mal chiadés, qui partent dans tous les sens, avec des libellés absolument pas explicites voire trompeurs. Après, c’est sur que si ta référence de qualité pour le code c’est du brainfuck…
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
J'ai juste pas voulu taper sur Python après l'exemple sur Ansible :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la spec, c'est le code
Posté par Renault (site web personnel) . Évalué à 6.
Plusieurs dizaines de milliers de lignes, ce n'est pas très gros hein. ;-)
Et cela ne change pas grand chose au problème, si tu as des briques plus élémentaires, il faut malgré tout concevoir et documenter les interactions entre elles. Ce n'est pas magique.
Et il faut forcément que quelqu'un puisse ou ait en tête l'architecture globale d'un projet, tu ne peux pas lui dire de lire le code d'une dizaine de modules pour qu'il comprenne l'architecture de l'ensemble. Cela n'a pas de sens.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Heu, comment dire, briques simples => communication entre briques => validation d'interfaces => documents d'interfaces. Je ne suis pas sûr que cela simplifie
Il y a des cas où la complexité du projet fait que non, tu ne t'amuses pas à découper en micro-services.
L'exemple C++ dont je parlais est un système de contrôle-commande qui pilote des automates de plus bas niveau alors comme tu gères la cohérence et la gestion d'un système complet interagissant avec d'autres systèmes, tu ne peux pas découper.
C'est vrai que vu qu'Ansible est codé en Python, il vaut mieux faire des petits trucs parce que c'est pas la compilation qui va t'aider à t'y retrouver en cas de refactoring.
Et puis, dans certains systèmes, le message tutu has no attribute fera beaucoup moins rire les utilisateurs.
[^] # Re: la spec, c'est le code
Posté par Renault (site web personnel) . Évalué à 8.
Bah non, la conception n'est pas le code source qui en est une implémentation.
Une spécification, qui est le résultat de la conception, ne peut être exprimée convenablement dans un code source car cela n'est pas son but. Le code source décrit un programme, des algorithmes.
Je veux dire, une spécification, ce n'est pas juste décrire les limites du programmes ou ce qu'il fait. C'est aussi expliquer des choix de conception. Et ça, tu en trouves rarement dans le code source. Et oui, ton produit n'a pas que des limitations techniques (genre le nombre d'imbrications du fichier JSON acceptable), c'est aussi exprimer que le système doit démarrer en moins de 60 secondes, que par défaut on souhaite qu'une certaine interface soit présentée, etc. Décisions qui impactent souvent des non codeurs (ergonomes, client, etc.) et qui ne sont pas dans le code source car son but n'est pas de collecter les comptes rendus de réunion de spécification mais d'expliquer son code.
Mouais, concevoir un logiciel un peu conséquent, cela prend des années. Certes le logiciel peut faire des mises à jour progressive, faire des prototypes et tout. Mais un gros projet c'est loin d'être si différent en coût par rapport à la production d'un bien manufacturé.
Puis le début de ta phrase est fausse. Le compilateur transforme le code source en un exécutable exploitable par la machine. Ce n'est pas lui qui conçoit et doit améliorer le logiciel à l'avenir. Si on va dans ton sens, un produit manufacturé n'a pas besoin de spécifications non plus, car comme c'est la chaîne d'assemblage qui réalise le produit final, il suffit de regarder la conf des machines outils, leur code source, la liste des matières premières et hop tu as tout ce qu'il faut ! C'est ridicule.
[^] # Re: la spec, c'est le code
Posté par whity . Évalué à 3.
Je suis entièrement d’accord, mais tout ça ne s’exprime pas non plus, à ma connaissance, avec UML.
C’est le problème que j’ai avec UML : un langage lui-même complexe, censé être universel mais qui en réalité ne l’est pas (C++ permet tout un tas de trucs pas représentables par UML, comme le move semantic ou le CRTP), et qui de toute manière sera incomplet car j’ai besoin d’autres documents de conception (ce que tu décris, ça relève de la gestion des exigences). Après, ça reste un très bon outil de visualisation pour la partie qui le concerne.
Mais rajoute à ça que les éditeurs UML que j’ai vu sont peu ergonomiques (je parle des gratuits, les payants sont probablement mieux), au final tu arrives à un meilleur résultat (càd plus productif) en écrivant le squelette de ton code et en générant les diagrammes avec un outil comme doxygen.
Ça ne le serait pas tant que ça si tu avais un outil qui, à partir de ça, te ressort le plan détaillé du produit manufacturé (le plan, pas le cahier des charges). Aujourd’hui c’est ce qu’on a sur le code. Maintenir un document séparé, non lié au code, avec tous les risques de désynchronisation que ça comporte, est à mon avis contre-productif par rapport à maintenir le même document, généré automatiquement à partir du code.
Du coup, soit on travaille tout sur le code, soit on travaille tout sur l’uml (pour de l’accès à une BDD, le code se génère très bien automatiquement), mais mixer les deux n’est pas une bonne idée.
Pour moi il y a une différence fondamentale : le bien manufacturé, une fois conçu, est produit à l’identique à des milliers ou millions d’exemplaire, parfois par des sous-traitants, etc. Je trouve que côté logiciel, on est plus proche de l’idée d’un bâtiment : un projet unique à chaque fois, dont la finalité peut évoluer au cours de la vie (pour un bâtiment, on parle en dizaines d’années voire en siècles tandis que pour un logiciel on parle d’années voire de mois). Du coup, l’amortissement du coût n’est pas le même, et les choix faits en conséquence différents.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 26 octobre 2017 à 11:18.
J'aime bien l'analogie avec un bâtiment, ça semble en effet plus proche de ce qu'on devrait faire dans le logiciel.
Le code source, ça serait donc l'équivalent des plans d'architecte.
La grosse différence, c'est que passer du code source au binaire prend au pire quelques heures (sur un très gros projet). Du coup, mettre le truc en production et continuer à faire des changements ensuite ne pose pas de problèmes, on peut facilement générer de nouvelles versions.
Par contre, en faisant ça on peut avoir plein d'autres problèmes (migrations de schémas de bases de données, ce genre de choses).
Mais pour revenir à l'exemple de la construction d'un aéroport qui a été mentionné plus haut: je ne crois pas que l'architecte se lance tête baissée dans la réalisation des plans. Je ne crois pas non plus que le plan donne toutes les informations. Par exemple, il n'indiquera pas le nombre de passagers par jour attendus, ce qui est quand même un élément important pour comprendre les choix qui ont été faits. Ou le type d'avions qu'on veut pouvoir accepter (la piste d'atterrissage est trop courte pour un A380: est-ce que c'est un problème?)
Changer ces données en cours de projet et essayer de modifier les plans pour correspondre, c'est pénible et compliqué. Même en ignorant la partie "compilation" ou construction du bâtiment à partir des plans. Au bou d'un moment, l'architecte en a marre que son client change d'avis tout le temps et il n'a pas envie de jeter ses plans et de tout recommencer une 15ème fois. C'est là que la qualité du travail fourni baisse.
Existe-t-il un atelier pour le développement très rapide de plans d'aéroports? Comment fait-il pour prendre en compte toutes les contraintes? (les montagnes ou buildings ou zones résidentielles à proximité, etc). Est-ce que ça marche aussi si on veut construire un port maritime ou une gare? ou un supermarché?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la spec, c'est le code
Posté par mzf (site web personnel) . Évalué à 2.
Je ne pense pas que ce que dise Uncle Bob est ridicule, vu les ouvrages de référence qu'il a écrit (Clean Code, principe SOLID, etc.).
Si on déroule l'analogie, la conf des machines outils et les programmes d'usinage peuvent être comparés à la mécanique interne du compilateur : l'utilisation d'un arbre syntaxique abstrait ou d'une représentation bytecode intermédiaire par exemple. Chaque compilateur a son fonctionnement propre, et chacun produira à peu près la même sortie à partir du même code source, de la même façon qu'à partir d'un plan de conception on produira à peu près toujours la même pièce même avec des machines différentes ou des procédés de fabrication différents.
Comme toute analogie, elle a ses limites, mais elle me parait légitimer le code en tant que document de référence qu'il faut garder le plus lisible possible.
[^] # Re: la spec, c'est le code
Posté par Renault (site web personnel) . Évalué à 8.
Tout n'est pas ridicule, mais il me semble en effet ridicule de croire que le code source contient toutes les informations utiles pour un projet d'envergure.
Sauf que, comme je l'ai dit, le code ne peut servir de référence ultime :
Le dernier point est souvent oublié mais il est capitale. J'ai bossé avec des non-codeurs et pour eux il est inconcevable qu'ils lisent du code ou qu'ils essayent de trouver l'info qui leur faut dans la documentation du projet qui est dans le code. Ils perdraient trop de temps.
Par exemple, perso je m'occupe souvent de l'interface noyau / matériel et noyau / logiciels. Je ne pouvais pas exiger des ingénieurs électroniciens de lire ma doc pour savoir ce que je fais avec leur matériel. Ils s'en foutent de l'architecture du noyau et des détails dont seul le logiciel a a s'en préoccuper. De même que moi je m'en fou de savoir exactement les plans de routage de la carte électronique dessous.
Résultat, nous devons concevoir une documentation pour décrire l'interface logiciel / matériel, quelle puce est accessible sur quel bus, les registres importants à changer, certaines possibilités en options, les changements exactes entre la version A du matériel et la version B, etc.
Non seulement c'est utile pour nous, éviter de perdre du temps à récupérer les infos pertinentes, cela nous permet d'éviter les erreurs car on doit dialoguer pour se mettre d'accord sur les tâches à faire. En plus comme le projet était en contexte aéronautique, nous devons fournir ce genre de document pour être audité par des non informaticiens (les ingénieurs systèmes).
Et avec les non programmeurs ? Bah c'est aussi utile. Pour beaucoup de programmeurs, le noyau est une boîte noire et doit le rester. Ils s'en foutent de l'architecture de mes pilotes, et en plus la plupart ne savent pas forcément coder en C. Comme pour le matériel, ce qui faut, c'est la description des entrées / sorties. Le reste tout le monde s'en fiche (sauf moi pour maintenir mon propre code). De même que je n'ai pas envie de plonger dans un code écrit dans un langage que je comprends mal pour vérifier si le format des entrées / sorties correspond. Et comme la doc en général ressort toute l'architecture, te peux prendre du temps pour identifier la section qui t'intéresse.
Tout cela pour dire quoi ? Que je trouve très important que l'on documente nos codes à différents échelons. Il faut décrire les interfaces d'entrées / sorties pour ceux qui vont dialoguer avec toi, il faut décrire l'architecture détaillée (dans le code) pour ceux qui vont coder ou reprendre ce module, et il faut décrire une architecture simpliste pour ceux qui vont gérer le projet et faire l'architecture / relecture globale. Cela demande différents niveaux d'abstractions, de formats de documents donc (fichier texte, UML et code). Croire que seul le code avec la doc généré suffit est je pense trop simpliste et ne peut fonctionner pour un projet d'envergure qui fait intervenir des non codeurs dans la procédure.
[^] # Re: la spec, c'est le code
Posté par guppy . Évalué à 3.
Je suis d'accord avec toi sur certains points : certains documents sont très utiles (celui qui décrit les entrées sorties par exemple, ceux qui documentent l'architecture également, et bien d'autres). Mais certains sont inutiles voir nuisibles : tous ceux qui concernent le code de manière trop précise sont voués à être désynchronisés. Je pense que pas mal de développeur ont vécu le cas où on leur file une doc et un code qui ont évolué séparément. A ce moment là les ennuis commencent ; ça doit expliquer certaines réactions épidermique sur cette dépêche.
Une solution est d'utiliser des softs genre doxygen qui évitera cette désynchronisation.
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Doxygen ce n'est pas de la magie.
Faire une documentation de qualité, c'est un métier et ça demande d'y passer du temps.
En fait, Doxygen peut même être nuisible pour ce genre de choses. L'idée est de mettre la documentation et le code dans le même fichier, en se disant que comme ça les gens vont peut-être mieux arriver à garder les deux synchronisés. Mais l'inconvénient, c'est que ça conduit souvent à une documentation qui est seulement une paraphrase du code: on va sagement mettre un gros commentaire Doxygen au début de chaque fonction et bêtement répéter ce que fait le code dedans. ça n'a aucun intérêt. Une documentation est utile quand elle arrive à prendre de la hauteur et à décrire l'architecture sans trop rentrer dans les détails.
Il y a des cas ou Doxygen marche plutôt bien, par exemple pour documenter les APIs d'un module. Il est possible de l'utiliser pour faire une documentation d'architecture complète, mais ça reste beaucoup de travail. Et surtout, c'est pénible de devoir inclure toute cette documentation dans les fichiers source, dont ça encombre la lecture. J'ai en tête un projet qui a trouvé une solution en mettant les commentaires Doxygen dans des fichiers séparés du code source pour éviter ce problème. Mais du coup, Doxygen n'a plus grand intérêt, si ce n'est de parser les fichiers .h du projet pour vérifier que les APIs documentées sont bien celles qui sont implémentées.
[^] # Re: la spec, c'est le code
Posté par Lutin . Évalué à 3.
L’intérêt est de comprendre à quoi est censée servir la fonction en question, en lisant juste le code je ne sais ce que fait la fonction effectivement, ça peut simplifier des tâches de debug.
De plus ça aide les nouveaux dev à entrer plus doucement dans un gros projet.
Avoir une documentation qui prend de la hauteur et décrit l'architecture sans trop entrer dans les détails, ça n'est pas le but de doxygen.
[^] # Re: la spec, c'est le code
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Je pense qu'il y un problème de vocabulaire. Une spécification vient avant le code, sinon on a un rapport d'architecture, ce qui est souvent plus utile qu'une spécification obsolète, on est d'accord.
Ce qui est vraiment utile, c'est un cahier des charges, justement sans aucune solution technique en tête, à base de scénario d'utilisateurs. C'est aux codeurs de trouver la meilleur technique. Même si les techniques agiles ont rendu l'absence de ce genre de document moins grave, la tache est toujours à faire.
"La première sécurité est la liberté"
# UML rapide ?
Posté par Xavier Combelle (site web personnel) . Évalué à 8.
et ca n'a jamais remplit ce but
[^] # Re: UML rapide ?
Posté par matthieu . Évalué à 0.
Si, le BPMN est du développement rapide d'applications.
Matthieu Giroux Rennes
# rédaction pas trop mal
Posté par papap (site web personnel) . Évalué à 8.
Je suis satisfait que les commentaires portent sur UML ou d'autres choses, mais pas sur la rédaction de la news elle-même qui nous a demandé pas mal de travail. C'était pas gagné au début.
[^] # Re: rédaction pas trop mal
Posté par matthieu . Évalué à -1.
TMS Software propose un cadriciel BPM payant et partagé.
Matthieu Giroux Rennes
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.