Discussion :

[Pyramidev]

le fait que ça aide quand même à acquérir une pensée structurée

Ou comment s'auto-persuader que tout ce travail fourni en classes prépa n'a pas servi à rien, à part intégrer une école d'ingénieur.

Je caricature. Les cours d'anglais étaient utiles.
En outre, quand j'apprends le langage Haskell, dans la bibliothèques standard, il y a plein de typeclasses qui ont un niveau d'abstraction similaire voire même parfois supérieur aux structures algébriques que j'ai vues en math, en prépa. Peut-être que les cours de math de prépa facilitent mon apprentissage du Haskell.
Par contre, je pense que la physique et la chimie des classes prépa n'ont pas d'impact sur l'apprentissage de la programmation.

[el_slapper]

Ou comment s'auto-persuader que tout ce travail fourni en classes prépa n'a pas servi à rien, à part intégrer une école d'ingénieur.

Là dessus, je suis d'accord. La prépa, c'est du bachotage. Ca montre juste qu'on a l'endurance pour tenir ce genre de folie.

Je caricature. Les cours d'anglais étaient utiles.

Les cours d'Allemand pour moi(avec une notation au concours bien plus favorable que l'anglais). Et puis comme j'étais en prépa techno, j'ai fait du dessin industriel(du vrai, pas de la descro rigolote mais sans utilité que faisaient les maths physique), ainsi que de l'atelier(ça a disparu de puis, mais je sais fraiser un carter de bagnole, ou tourner des outillages de grande précision).

En outre, quand j'apprends le langage Haskell, dans la bibliothèques standard, il y a plein de typeclasses qui ont un niveau d'abstraction similaire voire même parfois supérieur aux structures algébriques que j'ai vues en math, en prépa. Peut-être que les cours de math de prépa facilitent mon apprentissage du Haskell.

C'est impossible à mesurer. J'ai tendance à penser que oui, mais sans preuve.

Par contre, je pense que la physique et la chimie des classes prépa n'ont pas d'impact sur l'apprentissage de la programmation.

Les cours d'école d'ingé, nettement plus ancrés dans le monde réel, eux, m'ont servi. Spécialement la manière de penser derrière le SMED. Quelqu'un qui n'a pas eu ça pourra quand même mettre au point des optimisations d'urbanisme de code efficaces, mais j'ai toujours trouvé qu'un peu de théorie, ça aide à mettre en place des choses. Pas obligatoire, mais utile.

[wolinn]

Les langages permettant d'interagir avec un processeur quantique n'en sont qu'à leurs balbutiements, et pour mieux comprendre le bas niveau, je suis en train d'absorber la théorie du calcul quantique. Pour l'occasion, j'ai exhumé mon Cohen-Tannoudji, traité de mécanique quantique bien connu des étudiants en physique...
J'en avais bien bouffé pendant mes études, vers 1990, et je n'aurais jamais pensé ressortir cela un jour dans un tel contexte.

[Grogro]

Je caricature. Les cours d'anglais étaient utiles.
En outre, quand j'apprends le langage Haskell, dans la bibliothèques standard, il y a plein de typeclasses qui ont un niveau d'abstraction similaire voire même parfois supérieur aux structures algébriques que j'ai vues en math, en prépa. Peut-être que les cours de math de prépa facilitent mon apprentissage du Haskell.
Par contre, je pense que la physique et la chimie des classes prépa n'ont pas d'impact sur l'apprentissage de la programmation.

Actuellement non, mais si tu t'intéresse au deep learning tu y retrouveras énormément de physique statistique, et j'en ai été le premier surpris (mais au fond, modéliser un réseau de neurones qui peuvent être dans l'état actif ou inactif par du Ising ça parait assez naturel quand on y pense). En gros, des outils inventés pour comprendre l'aimantation des matériaux ferromagnétiques qui, des décennies plus tard, débouchent sur des avancées dans l'IA. C'est fascinant. On est bien au delà du niveau prépa certes, plutôt niveau M1.

Quant aux structures algébriques étudiées en prépa, la théorie des groupes est omniprésente dès qu'on soulève un peu le capot.

el slapper > c'est quoi des "optimisations d'urbanisme de code efficaces" et à quoi ça sert ? Comment ça s'apprend ?

[el_slapper]

(.../...)el slapper > c'est quoi des "optimisations d'urbanisme de code efficaces" et à quoi ça sert ? Comment ça s'apprend ?

bon, pardon pour ma verbosité excessive. L'urbanisme du code, en gros, c'est ce qui fait que les différents éléments d'une application complète sont organisés entre eux. Par exemple, si on a besoin d'un traitement de date qui dépasse le standard du langage(courant en bancaire, ou il y a des calendriers assez exotiques, comme le "target"), un urbanisme efficace centralisera toutes les gestions de date à un seul endroit, et quiconque a besoin de calculer une date target, ou un jour ouvré/ouvrable, devra passer par le même endroit. C'est aussi ce qui fait que les classes pour les RIB iront ici, les classes pour les comptes iront là, etc, etc..... Ca peut être à plus courte portée, vaut-il mieux faire 18 petits programmes pour convertir 18 fichiers aux formats proches, ou alors un seul programme maitre qui utilise au mieux les choses en commun?

C'est très dur à apprendre, je n'ai que quelques notions, et j'ai croisé de véritables maitres, qui ont appris surtout sur le tas. Mais la capacité à théoriser des comportements est essentielle dans ce domaine. Et j'ai tendance à penser que ce que j'ai appris en école d'ingé me sert pas mal quand j'essaye de progresser là-dedans.

[Mat.M]

En outre, quand j'apprends le langage Haskell, dans la bibliothèques standard, il y a plein de typeclasses qui ont un niveau d'abstraction similaire voire même parfois supérieur aux structures algébriques que j'ai vues en math, en prépa. Peut-être que les cours de math de prépa facilitent mon apprentissage du Haskell.

je ne suis pas tout à fait d'accord ; on ne peut pas comparer des classes d'un langage de programmation avec des structures algébriques puisque d'une part les mathématiques ne sont pas forcément la solution à tous les problèmes informatiques.
Ensuite les maths ce sont des théorèmes,axiomes, "tout fait" des sortes de modèles démontrables et vérifiables parce qu'ils obéissent à une logique numérique.
Pour finir quand on a une vision abstraite d'une chose qui permet de créer une objectivation conceptuelle , on y met un peu ce que l'on veut dans cette abstraction

[Grogro]

bon, pardon pour ma verbosité excessive. L'urbanisme du code, en gros, c'est ce qui fait que les différents éléments d'une application complète sont organisés entre eux. Par exemple, si on a besoin d'un traitement de date qui dépasse le standard du langage(courant en bancaire, ou il y a des calendriers assez exotiques, comme le "target"), un urbanisme efficace centralisera toutes les gestions de date à un seul endroit, et quiconque a besoin de calculer une date target, ou un jour ouvré/ouvrable, devra passer par le même endroit. C'est aussi ce qui fait que les classes pour les RIB iront ici, les classes pour les comptes iront là, etc, etc..... Ca peut être à plus courte portée, vaut-il mieux faire 18 petits programmes pour convertir 18 fichiers aux formats proches, ou alors un seul programme maitre qui utilise au mieux les choses en commun?

Intéressant. En gros, il s'agit de savoir prendre suffisamment de recul pour adopter une vision d'un architecte logiciel, voire d'une vision stratégique. Le problème que je constate souvent, à mon échelle, c'est que les développeurs ont trop souvent le nez dans le guidon, concentrés sur leur brique et oubliant parfois le mur qui va autour, ou les impacts du développement/correctif en cours sur les autres classes. Cela tient aussi au fait qu'on leur demande de travailler dans l'urgence sans toujours pouvoir prendre le temps de faire leurs tests unitaires ou faire de l'analyse avant de se lancer dans le code tête baissée. Il y a là aussi la problématique d'un management trop vertical : le travailleur n'est pas assez autonomisé, a souvent l'impression de n'être qu'un pion interchangeable (surtout quand on est presta), sans avoir son mot à dire et "faisant ce qu'on lui dit de faire".

Cet article me semble parlant à ce sujet : http://www.entreprise.news/lecons-de...al-mcchrystal/

"L’ouvrage Team of Teams est un condensé de l’expérience du général Stanley McChrystal, comme chef des forces spéciales (en Irak notamment). Confronté à une recrudescence des attentats suicides et d’autres actions de la part d’Al-Qaeda, il se rend très vite compte que le problème n’est pas tant l’ennemi que la manière dont fonctionne l’organisation militaire américaine : structure hiérarchique pesante, rivalités entre services de renseignement, manque de vision globale des individus ainsi que des tenants et aboutissants des missions…

Selon lui, la seule manière de sortir de l’ornière est d’adopter une organisation permettant, à la fois, une grande capacité de réaction ET un partage d’informations le plus complet possible. Ainsi, McChrystal favorise l’autonomie des forces spéciales avec prise de décision au plus près du terrain tout en organisant/renforçant les réunions quotidiennes des responsables des différentes agences de renseignement (CIA, NSA, FBI…) afin de fluidifier le partage. Les individus sont amenés à travailler ensemble, quel que soit leur organisation d’origine ou leur grade. Seule la mission compte.

Plus intéressant, McChrystal met en avant la nécessité de créer une vision partagée (il parle de shared consciousness), une confiance mutuelle, entre les différentes personnes, de l’analyste aux États-Unis au soldat des forces spéciales sur le sol irakien. En effet, une mission ne regroupe que quelques individus, travaillant en équipe et disposant d’une autonomie. D’où le titre de l’ouvrage, qui est aussi sa maxime organisationnelle : une équipe d’équipes, c’est-à-dire un groupe adaptable, avec des individus venant d’horizons différents, susceptibles d’aller chercher des informations dans leur corps d’origine afin d’assurer le succès de la mission."

C'est précisément toutes les problématiques qu'on rencontre au quotidien dans notre métier.

C'est très dur à apprendre, je n'ai que quelques notions, et j'ai croisé de véritables maitres, qui ont appris surtout sur le tas. Mais la capacité à théoriser des comportements est essentielle dans ce domaine. Et j'ai tendance à penser que ce que j'ai appris en école d'ingé me sert pas mal quand j'essaye de progresser là-dedans.

Je me souviens que tu es spécialisé dans la qualité logicielle. En quoi les méthodes classiques de management de la qualité, utilisées dans l'industrie, peuvent nous aider dans nos projets IT et particulièrement les fameux "projets cathédrales" ? Comment les appliquer ?

[Pyramidev]

En outre, quand j'apprends le langage Haskell, dans la bibliothèques standard, il y a plein de typeclasses qui ont un niveau d'abstraction similaire voire même parfois supérieur aux structures algébriques que j'ai vues en math, en prépa. Peut-être que les cours de math de prépa facilitent mon apprentissage du Haskell.

je ne suis pas tout à fait d'accord ; on ne peut pas comparer des classes d'un langage de programmation avec des structures algébriques

Un exemple tiré du Haskell sera plus parlant qu'un long discours.

Dans un premier temps, voici deux typeclasses qui sont des structures algébriques simples tirées des mathématiques (niveau Bac+1) :

La bibliothèque standard du Haskell définit la typeclass SemiGroup dont tous les sous-types doivent implémenter une opération <> qui doit être associative :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Pour tous x, y et z :
x <> (y <> z) = (x <> y) <> z

Parmi les sous-types de SemiGroup, il y a la typeclass Monoid dont tous les sous-types doivent définir, en plus de <>, un élément neutre mempty pour la loi <> :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Pour tout x :
x <> mempty = x
mempty <> x = x

À présent, voici un exemple concret qui utilise la typeclass Monoid :

La bibliothèque standard définit la typeclass Foldable qui, en gros, est un conteneur pour lequel il faut définir comment on le parcourt. L'utilisateur doit définir soit la fonction foldMap, soit la fonction foldr, soit les deux. En fait, chacune des deux est définie par défaut en fonction de l'autre et elles doivent être cohérentes. Je ne détaillerai que foldMap.

Pour tout Foldable t, pour tout Monoid m, pour tout type a, pour toute fonction f de type a -> m,foldMap f, à savoir l'image de f par la fonction foldMap est elle-même une fonction de type t a -> m, c'est-à-dire une fonction qui prend en paramètre un "conteneur" d'éléments de type a et retourne un élément de type m.

En Haskell, la notation correspondant à ce que je viens de dire est : foldMap :: Monoid m => (a -> m) -> t a -> m.

Par exemple, soit un arbre binaire défini ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)

Cela se lit : pour tout type a, définissons un arbre dont les éléments sont de type a.
Un arbre est soit vide, soit une feuille (donc n'ayant qu'un seul élément), soit un triplet (sous-arbre de gauche, élément du sommet, sous arbre de droite).

En Haskell, on peut définir Tree comme un sous-type de Foldable ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
instance Foldable Tree where
   foldMap f Empty = mempty
   foldMap f (Leaf x) = f x
   foldMap f (Node leftSubTree x rightSubTree) = (foldMap f leftSubTree) <> ((f x) <> (foldMap f rightSubTree))

Ici, foldMap est une fonction récursive qui appelle f sur chaque élément de l'arbre et qui fusionne les résultats avec <>.
La ligne foldMap f Empty = mempty indique que, pour un arbre vide, on retourne l'élément neutre du monoïde m.
La ligne suivante indique que, pour un arbre d'un seul élément, on retourne l'image de cet élément par la fonction f.
La dernière ligne décrit comment gérer un arbre qui a des sous-arbres. J'ai ajouté des parenthèses redondantes pour qu'on puisse lire le code sans que l'on ait besoin de connaître les règles du Haskell sur les opérateurs.

Applications :

• Pour tout type numérique Num (par exemple int), pour définir la somme des éléments de n'importe quel Foldable Num (par exemple Tree int), on fait foldMap Sum avec Sum une fonction qui à tout nombre associe un nombre sous la forme d'un monoïde dont l'élément neutre est 0 et dont la loi associative est +.
• Pour définir le produit des éléments de n'importe quel Foldable Num, on fait foldMap Product avec Product une fonction qui à tout nombre associe un nombre sous la forme d'un monoïde dont l'élément neutre est 1 et dont la loi associative est la multiplication.
• Dans un Foldable, pour chercher l'éventuel élément qui est le premier (dans le sens de parcours défini par foldMap) à répondre à un certain critère, on passe aussi par un monoïde. Ce sera un monoïde de type "soit un élément trouvé, soit rien" dont l'élément neutre est "rien" et dont la loi associative privilégie le premier élément trouvé :
  ("élément trouvé x" <> "élément trouvé y") vaut "élément trouvé x".
• Dans un Foldable, pour vérifier que tous les éléments respectent un certain critère, on utilise foldMap avec une fonction qui à tout élément associe un booléen sous la forme d'un monoïde dont l'élément neutre est True et dont la loi associative est && (le ET logique).

Remarque : dans mes 4 exemples ci-dessus, du côté des développeurs Haskell, on n'a pas besoin de manipuler directement ces monoïdes, car ce travail est déjà fait dans la bibliothèque standard : on passe par des fonctions de plus haut niveau sum, product, find et all dont les implémentations utilisent les monoïdes que je viens de décrire.

La bibliothèque standard définit plein de typeclasses dans le même genre, parfois bien plus complexes tout en restant très abstraites, par exemple la typeclass Monad, qui a un rôle central en Haskell.

Edit 2018-04-24-23h21 : ajout de l'exemple de la fonction all.
Edit 2018-04-25-11h25 : amélioration de quelques formulations.
Edit 2018-04-25-13h05 : correction d'une faute de français et retrait d'un lien Wikipédia anglais qui explique mal les monades.

[el_slapper]

Ou là, j'ai voulu faire simple, tu me réponds avec un pavé bourré de subtilités et d'élégance, et je vais être obligé de faire dans le complexe, le compliqué, et le subtil aussi. en essayant d'être élégant aussi(mais je ne promets rien).

Intéressant. En gros, il s'agit de savoir prendre suffisamment de recul pour adopter une vision d'un architecte logiciel, voire d'une vision stratégique. Le problème que je constate souvent, à mon échelle, c'est que les développeurs ont trop souvent le nez dans le guidon, concentrés sur leur brique et oubliant parfois le mur qui va autour, ou les impacts du développement/correctif en cours sur les autres classes. Cela tient aussi au fait qu'on leur demande de travailler dans l'urgence sans toujours pouvoir prendre le temps de faire leurs tests unitaires ou faire de l'analyse avant de se lancer dans le code tête baissée. Il y a là aussi la problématique d'un management trop vertical : le travailleur n'est pas assez autotomisé, a souvent l'impression de n'être qu'un pion interchangeable (surtout quand on est presta), sans avoir son mot à dire et "faisant ce qu'on lui dit de faire".

Ou alors qu'il n'est pas sensibilisé aux problématiques transversales. Tiens, là, je sors d'entretien mensuel avec mon chef, qui fait aussi les builds. Il râlait, parce-que 2 programmeurs(dont le lead technique...) ont tendance à se faciliter la vie et à ignorer la sienne, ou celle du support. Dernier exemple. Ils ont fait une erreur, et ont fait une modif dans la mauvaise version majeure. Résultat, ils ont fourni à mon chef de quoi faire un build incomplet... mais ont installé chez un client à la main le correctif. Résultat, la version ùµ$£.#@+ contient l'évol dans certains cas, et pas dans d'autres, ce qui va rendre le travail du support très compliqué. Pour gagner trois minutes de leur coté, il vont couter un paquet d'heures à d'autres endroits de la boite.

Le problème n'est même pas là. Le problème, c'est que quand on leur dit de faire gaffe, ils répondent "tu fais chier, on sait ce qu'on fait". Parce-qu'ils n'ont pas cette culture de travail en harmonie entre les équipes. Possiblement parce-que l'ancien management était trop vertical(j'en sais rien, j'étais pas là, mais l'ancien propriétaire était une boite immense pour qui le logiciel n'était qu'une couteuse diversification, avec un vision industrielle à l'ancienne, alors sans être sur, ton explication est très possible).

Après, j'ai été dans des situation ou la hiérarchie pratiquait le management par la panique, et on nous les consultants étions fiers de garder notre sang-froid. Notre mot d'ordre était "ici, c'est un banque, aucun problème n'est vital, ça n'est jamais que du pognon". Et nous résolvions les problèmes dans le calme. Mais tous les consultants ne sont pas, encore une fois, sensibilisés à l'importance d'avoir une vision globale. Les managers, encore moins. On les forme trop dans un esprit possessif, du genre "le management, c'est la science du contrôle".

Cet article me semble parlant à ce sujet : http://www.entreprise.news/lecons-de...al-mcchrystal/
(.../...)
C'est précisément toutes les problématiques qu'on rencontre au quotidien dans notre métier.

Bon, je sais ce que je demande pour mon prochain noël, moi, merci du tuyau. D'ailleurs, c'est un peu ce que mon chef essaye de mettre en place. Communication avec les autres équipes qualité, communication avec le développement(ça marchouille parfois), le support(ça marche presque, tant que la chef support ne fait pas un caca nerveux en hurlant que c'est son équipe à elle seule), l'implémentation(ça marche quand les gens de l'implémentation arrivent à sortir la tête de l'eau, donc pas si souvent).

Évidemment, ça ne peut marcher qu'avec des gens capables d'autonomie(ça tombe bien, c'est un critère de recrutement chez nous) et des hiérarchies intermédiaires qui jouent le jeu, et acceptent de ne pas avoir un contrôle divin sur leurs équipes(et ça, c'est plus dur).

Je me souviens que tu es spécialisé dans la qualité logicielle. En quoi les méthodes classiques de management de la qualité, utilisées dans l'industrie, peuvent nous aider dans nos projets IT et particulièrement les fameux "projets cathédrales" ? Comment les appliquer ?

Sur un projet cathédrale, mettons un projet ou l'approche cathédrale est justifiée(genre réglementaire big bang façon Bâle 2, ou migration technique big bang), le bon vieux "dire ce que l'on va faire, faire ce que l'on a dit que l'on avait fait, et vérifier qu'on a bien fait ce que l'on avait dit qu'on allait faire", même si il est officiellement obsolète, peut toujours servir. A condition de ne pas être rigide dessus et de rajouter dans la partie "dire" tout ce qu'on trouve alors qu'on en est déjà à la partie "faire".

Un exemple qui me vient à l'esprit est un énorme projet cobol dont la spécification complète, absolue et totale était la suivante : "le numéro de contrat passe de 7 à 9 caractères". J'adore cobol, sa rigidité est très souvent un atout à la maintenance et à l'exploitation, mais là, c'était juste colossal, alors que dans un langage plus dynamique, ben, on aurait juste recompilé et nettoyé deux-trois scories. Là, il fallait être industriel. Donc, répertorier tous les programmes, un par un(il y en avait 800), les modifier, pareil pour les bases(1200), pareil pour les définitions de fichiers(700), pareil pour les états(450) et encore d'autres trucs.

Là, pas le choix, une planification à l'ancienne, limite chantier de construction, ou on fait un WBS hyperdétaillé, et ou le but du jeu est juste de ne rien oublier, est inévitable. Avec un Gantt ou équivalent pour suivre l'avancement des tâches de développement. Et un autre pour les tâches de test. J'étais là-dessus, mon job était de créer la macro VBA/Excel qui allait générer en dynamique les paramètres pour l'outillage de comparaison des fichiers/bases/état - et qui allait les encoder dans un format compréhensible pour le mainframe. Chaque exécution des batches à fin de test était planifiée plusieurs mois à l'avance. C'était le job de mon voisin : pendant plusieurs mois, il a exécute des batches à la main, en suivant le plan exact. Il détestait son boulot(on le comprend). Il a été très pro. D'autres ont créé le comparateur, d'autres encore ont analysé les écarts(et il y en a eu un paquet) et remonté les anomalies au dev.

Le truc, c'est que ce genre de projets ou la cathédrale est justifiée, ça doit être 10/20% des projets informatique(en tous cas en gestion, c'est probablement différent en embarqué). Ce n'est valable que si le périmètre est fixé, et facile à identifier(Louvois, le périmètre est fixé, mais va le décrire avec précision...). Dans 80*90% des cas, le périmètre sera amené à changer en cours de projet, pour des raisons business parfaitement justifiables. Et donc, c'est le bazar. Les méthodes industrielles ne sont pas applicables, en tous cas pas à l'échelle du projet. Un WBS détaillé sera trop maltraité et impossible à mettre à jour.

Par contre, plus dans le détail, des choses issues de l'industrie sont toujours utilisables. le SMED que j'avais cité, c'est de l'agile, façon industrielle. Que j'avais découvert en injection thermoplastique. Au lieu de prendre 1h30 à changer un moule, on ne met plus que 6 minutes. En trichant de tous les cotés : fixation par aimants plutôt que par serrage, interfaces moule-machine standardisées et surtout déjà branchées sur le moule quand il est stocké à l'entrepôt, tailles standard de moules, etc..... C'est super utile, parce qu'on peut soudain se permettre de planifier la production à la journée et non plus au mois. L'équivalent en informatique, c'est tout ce qui permet de modifier rapidement une exécution. Souvent, ça sera des paramètres faciles d'accès. Parfois, ça m'est arrivé, ça sera du code, qui, correctement centralisé, permettra de changer nombre de flux de manière fluide.

Là, on est plus du tout dans la gestion de projet, on est vraiment dans les détails implémentation. Et chaque situation est différente, je pourrais donner des exemples, mais ils seraient trop spécifiques pour être adaptés ailleurs, c'est l'état d'esprit qui compte. Personne ne va mettre des aimants sur ses programmes pour les installer plus vite. Par contre, chercher ce qui peut être modifié/modularisé/centralisé pour améliorer la réactivité et l'agilité, oui, ça, ça peut être universel. Et c'est ça que j'ai appris en école d'ingé. Beaucoup le font sans avoir la théorie pour, ni le vocabulaire. C'est plus facile quand on a la théorie et le vocabulaire, je trouve.

[Invité]

Ça digresse totalement...
En tout cas, depuis que Glutinus a osé faire un rapprochement entre born2code78 et youness78, on n'a plus eu de nouvelles de born2code78

[Pyramidev]

Erratum : Dans mon précédent message, il faut remplacer int par Int.
Mais il est trop tard pour l'éditer. Désolé pour le double message.

[Mat.M]

En quoi les méthodes classiques de management de la qualité, utilisées dans l'industrie, peuvent nous aider dans nos projets IT et particulièrement les fameux "projets cathédrales" ? Comment les appliquer ?

bonjour, l'Industrie et les projets informatiques ce sont deux choses différentes.
Dans un processus industriel on peut produire à la chaine par exemple une machine outil réglée pour débiter peut produire beaucoup de pièces.
Un projet informatique c'est totalement différent et pas toujours facile à "industrialiser" même s'il existe des outils destinés à ça ( notamment les ERP)
Pour la simple raison qu'un projet informatique en particulier ne ressemble à aucun autre, il faut tout recréer, bref à chaque fois ça tient du prototype..

[Glutinus]

Reçu ce jour (datant d'hier) un message de born2code78.

@born2code78 : si tu repasses par ici, sache que je ne réponds pas aux questions "techniques par mp". Qui plus est, je trouve que la démarche que tu évoques dans ton mail est assez moyenne, mais par respect de ton mp je ne le répèterai pas. Libre à toi de le répéter ici, sachant que tu te prendras peut-être quelques critiques.

Par contre je citerai : "salut je te contacte en MP car j'ai déjà posté sur developpez.net à propos de ma situation mais je n'ai pas eu de réponses concrètes."

Si tu revenais lire régulièrement les réponses des membres à tes posts, et réponds aux éclaircissements demandés, tu aurais peut-être aujourd'hui plus de réponse quant à ce que tu pourrais ou devrais faire par la suite. Je t'invite donc à reprendre le fil.

Personnellement, ça me conforte dans l'idée que tu ne fais qu'un avec youness78