En faisant court : tu as défini un périmètre, mais c'est une des visions qui existent du logiciel, propre à l'ingénierie informatique mais certainement pas à "l'informatique" dans toutes ses ramifications et branches. Encore moins de ce qui est attendu aujourd'hui dans les organisations. J'insiste là-dessus.
Amha, ça mérite d'avoir un débat plus large, de qui (me) semble intéressant sur la définition finalement, de ce que c'est le développement et son attendu. Mon propos n'est pas de dire que tu as tort (tu n'as pas tort), mais que ta position ne me semble pas tenir lieu d'une généralité.
En faisant long : Si tu ne veux pas bouger de ton périmètre alors soit, mais ne me dit pas que je cherche "par tous les moyens" de mon côté. Que tu déjuges ou déconsidères un argument, ne le rend pas inopérant pour autant, parce que tu restes sur le pas de ta porte.
Le projet que j'ai soumis est "parfaitement imparfait" : une proposition sur des travaux perso., toujours en cours pour la meilleure approche.
Sur la question de l'orientation attendue sur la performance, le sujet a été débattu dès 1958/59, où les travaux plus universitaires ont accentué leur séparation avec l'ingénierie informatique pure émergente. L'histoire est connue :
- la branche "proche système" (au démarrage impérative, avec Fortran, C, etc.) ;
- (vs) la branche "abstractive" (Lisp et dérivés, les AST, le fonctionnel).
... Entre ceux qui vont exploiter complètement la puissance de calcul de la machine (qui iront très vite dans les entreprises, désireuses d'investir à moindre coût dans une informatisation extrêmement coûteuse), et ceux qui en veulent d'abord un usage généraliste, une "intelligence artificielle" - nb : le terme a l'époque porte sur les systèmes expert, la faculté de décision et de raisonnement pour une machine ; rien à avoir avec notre acceptation moderne : on est alors sur des systèmes de résolution d'assertions.
Notre débat est une ramification grossière de ces deux visions, qui se sont affrontées, avant de devenir plus complémentaires et de concert.
On avait encore à l'époque une grande diversité d'architectures matérielles et parfois, même pas de distinction dans les types de "mémoire" (je pense aux premières machines LISP, avec quelques parallèles que l'on peut faire avec l'approche choisie par Intel sur Optane Memory).
Avec en toile de fonds, la prise de possession par les sciences de gestion d'une partie des sciences informatiques avant qu'elles ne deviennent, au sein des organisations durant le milieu / fin des années 70, une entité de recherche et d'application indépendante.
Dit autrement : le logiciel est bien plus que qu'un assemblage applicatif, de scripts ou de codes divers. Il n'est pas éthéré et vient dans un SI qui est l'organisation elle-même. Il répond à un besoin (métier) et n'y a aucun autre intérêt, aucun but, aucun moyen à dépenser qui n'y soit pas rattaché. L'optimum d'un traitement strictement machine dont tu parles, était vrai il y a longtemps, où l'octet coûtait cher et les machines """rares""" (fin des années 90/début 2000). Cela reste largement enseigné dans les études informatiques, notamment celles où l'ingénierie est reine. Cependant ce n'est pas forcément une attente économique.
Désormais l'optimum est à chercher entre le coût de développement et de maintenance (ton salaire et celui de tes homologues n'est pas gratuit : optimiser un programme n'est pas toujours financièrement intéressant) ; la rentabilité d'un processus organisationnel qui l'utilisera (un logiciel très performant mais que personne ne maîtrise est détourné, abandonné ou pire pas maintenu par de futures équipes) ; la capacité à en extraire de l'information utile et à se justifier (audit, suivi et maîtrise, etc.) ; dernièrement les questions de sécurité et de sûreté, comme de la tolérance du SI aux pannes et à la gestion de la redondance.
Perdre 5% ou 10% de performance d'un logiciel n'est pas toujours un drame, même en augmentant les charges d'infras derrière. Parce que tes choix comme DSI ou proche de la DSI, sont contraints par des aspects sociaux, légaux, métiers - tout ce que tu veux.
Je ne parle même pas de la dette technique, qui pour le coup, parfois, oblige à des recherches très pointues sur l'optimisation "du 2Go/s pour un JSON" parce que l'architecture globale est déficiente, ou simplement n'est plus adaptée, ou face à un soucis hors norme de masse (tout le monde n'est pas Netflix, Facebook... !). Dans la quasi-totalité des organisations, on cherche donc moins à dépasser la dette que la contourner à moindre coût (souvent, cela revient à ne pas arrêter la production, ni modifier trop en profondeur un équilibre logiciel fragile, non-documenté, bloquant des refontes plus larges). Là effectivement, l'impératif d'efficacité peut se faire jour avec force. La fréquence de cette recherche d'efficacité en fait une généralité, mais pas un fait systématique et encore moins un but. Je tente de ne pas mélanger la cause et la conséquence.
Pour la maîtrise de l'architecture, encore faut-il avoir donc pensé aux points de la scalabilité et de la redondance - et là où nous pouvons nous rejoindre, c'est que Robert n'a certainement pas atteint l'objectif (mais après tout, c'est une proposition initiale, personne n'est contraint d'en faire usage...).
Ce n'est pas un effet de style si on est passé d'une qualification de "système informatique" (et donc de direction informatique) à "système d'information" (et donc de "direction des systèmes d'information"). Il y a une logique derrière. Personnellement ça ne me dérange pas qu'on considère que l'informatique n'est qu'elle-même, un concept un peu "indépassable", mais c'est un signe si les "cellules de gestion de projets" et autres modalités d'organisations se multiplient dans les DSI pour modifier les habitudes et les approches.
"par la magie des discours commerciaux, on s'éloigne du sujet"
Je n'ai rien, absolument rien à te vendre : je ne te rapporte pas un propos commercial, je ne te vends pas du rêve ; je te donne mon opinion de ce que j'ai pu trouvé après des heures à la bibliothèque universitaire ou en entretien. Tu ne prendras certainement pas les arguments, mais toi comme moi, nous nous ne nous adressons pas à l'autre mais aux lecteurs qui nous ont le mérite de nous lire.
Et je t'assure, évoquer les sciences de gestion dans les années 70 ou l'intérêt d'un travail ontologique au sein d'une organisation pour piloter le schéma de données et le développement applicatif d'une DSI n'a rien de bandant ! Au contraire, ça provoque le rejet et l'impatience (voire une pointe de mépris...).
Anecdote : lors de ma soutenance, mon jury me dit "propos passionnant, innovant [en réalité pas tant que ça, je fais une synthèse de travaux d'autres horizons pas encore rapprochés]. Comment voulez-vous vendre ça à une entreprise ?!" -> Je ne peux pas. L'historique culturel est en défaveur de l'approche "organisationnelle" des SI... mais des signes commencent à émerger.
Illustrons le propos. Un exemple que je suis attentivement : la ré-émergence du "no-/low-code", les services Amazon Lambda (idem chez Microsoft, IBM, Google... ces 3 dernières années), l'approche "fonctionnelle" sur tout un tas de langages très différents et une logique événementielle. Le schéma global de ces services :
1. un événement quelconque
2. un filtre
3. une fonction déclenchée, éventuellement avec la notion de grappes de travail derrière
4. une réponse renvoyée et/ou stockée.
Plutôt que d'agir sur l'efficacité d'une fonction, on dimensionne sa réplication (maîtrise des coûts : arbitrage sur le temps de calcul global plutôt que l'efficacité unitaire). L'orchestration des fonctions entre elles, créée l'applicatif. En gros tu as un stock de fonctions (ou de fonctionnalités, c'est-à-dire de sous-applicatifs), qui tu lies entre elles, de manière arbitraire, possiblement sans ligne de code pour l'utilisateur final.
Ces services cherchent justement à minimiser les coûts globaux pour les clients. Ils reprennent de vieilles théories, qui ont facilement 30 ans, avec les systèmes experts, qui eux-même n'avaient aucunement besoin de personnes ayant des talents de codeurs pour faire des logiciels (je pense à CLips par exemple*), en l'adaptant à ce qui est possible aujourd'hui.
Réellement, ce n'est ni plus ni moins que la ré-invention un poil modernisé des systèmes experts.
(* : L'expression choisie était celle des maths en inspiration, car il n'y avait pas guère de possibilités d'une interface évoluée. Ce n'est plus le cas aujourd'hui et je serais heureux le jour où une personne qui n'a pas de compétence informatique, sera capable de faire un logiciel convenable, avec un code généré propre et relativement bien pensé, parce qu'il se sera concentré sur les besoins de son métier et pas plus. On y arrive, doucement.)
Le but est de moins chercher cette partie d'optimisation purement mixte logicielle/matérielle, mais d'aller vers une meilleure applicabilité du logiciel au global et pour répondre aux exigences des procédures. C'est le sens de l'histoire : sinon autant rester à l'assembleur (zéro abstraction, tu n'auras pas mieux en terme de performance).
Deux des exemples qui allient beaucoup de facettes que j'évoque :
- le projet européen SPECIAL (l'application d'une politique de sécurité à maillage très fin sur n'importe quel d'objets) https://www.specialprivacy.eu/
- la thèse doctorale de Jérémy Lhez sur le "Filtrage, stockage et raisonnement sur de grands volumes de triplets RDF ordonnancés" https://pastel.archives-ouvertes.fr/tel-02084022/document
Comme je l'ai indiqué auparavant dans les commentaires, c'est bien le métier qui fait l'outil et pas l'outil qui fait le métier. Il doit donc être efficient et après, éventuellement, performant.
Les grandes boîtes ont un temps d'avance du fait de leurs moyens justement, et elles ne sont déjà plus sur la question de la numérisation (terminée) mais de l'abstraction de leurs outils numériques (SAAS, "cloudification" et autres) :
- elles ne veulent plus piloter du code mais une interface et un traitement logique (interface + traitement = logiciel) ;
- elles veulent davantage de développements rapides (c-à-d écrits vite) et efficients ;
- elles ne veulent plus gérer de la dette technique ni de contraintes organisationnelles trop fortes à cause de problématiques informatiques.
L'efficacité (en octets traités/seconde), les profils techniques pointus, arrivent après, en support pour rester dans du temps de calcul raisonnable mais pas en chef orchestre ni en finalité (exemple des "product owners" qui ne sont plus plus des pilotes techniques et couvres d'abord les attentes fonctionnels).
Pour le reste :
- tu es probablement un très bon programmeur et je ne doute pas une seconde que tu aies une meilleure connaissance que moi, notamment pour la gestion fine stack ou heap. Pour Robert, ma priorité est davantage la mise en grappe du processus que l'usage de la mémoire, tout en continuant à assurer la possibilité de soutenir un modèle RDF ;
- tu as entièrement raison un protocole binaire est plus efficace qu'un protocole qui se lit humainement. Mais j'ai préféré qu'il soit lisible par le plus grand nombre (dans l'espace francophone). Sur le sujet nos positions sont irrésolubles.
Enfin et pour conclure là, les hypothèses sur lesquelles j'ai travaillé ces dernières années et qui me motivent encore aujourd'hui. Elles n'ont aucune force de lois. Je les donne ici, pour parfaire le contexte de mon propos.
A. HYPOTHÈSE N°1 – « IL EXISTE UN ‘AUTRE CHEMIN’ POUR LES SI. »
Deux visions historiques s’affrontent dans les années 70 : les sciences de gestion (« vision organisationnelle ») ainsi que les ingénieurs de la micro-informatique naissante (« vision techniciste »).
La « vision techniciste » est celle qui a été très quasi-exclusivement sélectionnée par les organisations, comme choix par défaut qui n’est que rarement motivé « consciemment », devenant une sorte d’habitude collective.
Il est légitime, voire nécessaire dans certains cas, de remettre en cause cette « vision techniciste » et sortir de la dette technique mais aussi la dette organisationnelle créée par les outils informatiques.
B. HYPOTHÈSE N°2 – « LE SI EXISTE DANS DES CADRES HUMAINS TRÈS CONTRAINTS. »
La finalité sociale, comme le droit, n’autorisent pas toutes les « formes » d’outils informatiques. Certains de ces outils informatiques peuvent engendrer des rejets sociaux.
La finalité sociale comme le droit sont non seulement légitimes, évoluant au gré de la société (exemple avec la RSE), mais également des phénomènes permanents et coercitifs dans les organisations et leur histoire. Le débat est endogène à toute organisation.
La finalité sociale comme le droit, sont des sources de menaces mais aussi d’opportunités, qui agissent sur le système d’information.
C. HYPOTHÈSE N°3 – « LA DIRECTION DES SI DOIT DÉSORMAIS ÉVOLUER FORTEMENT. »
La Direction des Systèmes d’Information ne doit pas être un « frein » aux métiers – comme c’est trop souvent le cas.
La DSI doit être isomorphe à l’organisation et aux circuits d’information formalisés et non-formalisés.
La DSI ne doit pas être un centre technique de l’information, mais l’appui du centre de pilotage de l’information.
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
[ante scriptum : mon dernier commentaire]
En faisant court : tu as défini un périmètre, mais c'est une des visions qui existent du logiciel, propre à l'ingénierie informatique mais certainement pas à "l'informatique" dans toutes ses ramifications et branches. Encore moins de ce qui est attendu aujourd'hui dans les organisations. J'insiste là-dessus.
Amha, ça mérite d'avoir un débat plus large, de qui (me) semble intéressant sur la définition finalement, de ce que c'est le développement et son attendu. Mon propos n'est pas de dire que tu as tort (tu n'as pas tort), mais que ta position ne me semble pas tenir lieu d'une généralité.
En faisant long : Si tu ne veux pas bouger de ton périmètre alors soit, mais ne me dit pas que je cherche "par tous les moyens" de mon côté. Que tu déjuges ou déconsidères un argument, ne le rend pas inopérant pour autant, parce que tu restes sur le pas de ta porte.
Le projet que j'ai soumis est "parfaitement imparfait" : une proposition sur des travaux perso., toujours en cours pour la meilleure approche.
Sur la question de l'orientation attendue sur la performance, le sujet a été débattu dès 1958/59, où les travaux plus universitaires ont accentué leur séparation avec l'ingénierie informatique pure émergente. L'histoire est connue :
- la branche "proche système" (au démarrage impérative, avec Fortran, C, etc.) ;
- (vs) la branche "abstractive" (Lisp et dérivés, les AST, le fonctionnel).
... Entre ceux qui vont exploiter complètement la puissance de calcul de la machine (qui iront très vite dans les entreprises, désireuses d'investir à moindre coût dans une informatisation extrêmement coûteuse), et ceux qui en veulent d'abord un usage généraliste, une "intelligence artificielle" - nb : le terme a l'époque porte sur les systèmes expert, la faculté de décision et de raisonnement pour une machine ; rien à avoir avec notre acceptation moderne : on est alors sur des systèmes de résolution d'assertions.
Notre débat est une ramification grossière de ces deux visions, qui se sont affrontées, avant de devenir plus complémentaires et de concert.
On avait encore à l'époque une grande diversité d'architectures matérielles et parfois, même pas de distinction dans les types de "mémoire" (je pense aux premières machines LISP, avec quelques parallèles que l'on peut faire avec l'approche choisie par Intel sur Optane Memory).
Avec en toile de fonds, la prise de possession par les sciences de gestion d'une partie des sciences informatiques avant qu'elles ne deviennent, au sein des organisations durant le milieu / fin des années 70, une entité de recherche et d'application indépendante.
Dit autrement : le logiciel est bien plus que qu'un assemblage applicatif, de scripts ou de codes divers. Il n'est pas éthéré et vient dans un SI qui est l'organisation elle-même. Il répond à un besoin (métier) et n'y a aucun autre intérêt, aucun but, aucun moyen à dépenser qui n'y soit pas rattaché. L'optimum d'un traitement strictement machine dont tu parles, était vrai il y a longtemps, où l'octet coûtait cher et les machines """rares""" (fin des années 90/début 2000). Cela reste largement enseigné dans les études informatiques, notamment celles où l'ingénierie est reine. Cependant ce n'est pas forcément une attente économique.
Désormais l'optimum est à chercher entre le coût de développement et de maintenance (ton salaire et celui de tes homologues n'est pas gratuit : optimiser un programme n'est pas toujours financièrement intéressant) ; la rentabilité d'un processus organisationnel qui l'utilisera (un logiciel très performant mais que personne ne maîtrise est détourné, abandonné ou pire pas maintenu par de futures équipes) ; la capacité à en extraire de l'information utile et à se justifier (audit, suivi et maîtrise, etc.) ; dernièrement les questions de sécurité et de sûreté, comme de la tolérance du SI aux pannes et à la gestion de la redondance.
Perdre 5% ou 10% de performance d'un logiciel n'est pas toujours un drame, même en augmentant les charges d'infras derrière. Parce que tes choix comme DSI ou proche de la DSI, sont contraints par des aspects sociaux, légaux, métiers - tout ce que tu veux.
Je ne parle même pas de la dette technique, qui pour le coup, parfois, oblige à des recherches très pointues sur l'optimisation "du 2Go/s pour un JSON" parce que l'architecture globale est déficiente, ou simplement n'est plus adaptée, ou face à un soucis hors norme de masse (tout le monde n'est pas Netflix, Facebook... !). Dans la quasi-totalité des organisations, on cherche donc moins à dépasser la dette que la contourner à moindre coût (souvent, cela revient à ne pas arrêter la production, ni modifier trop en profondeur un équilibre logiciel fragile, non-documenté, bloquant des refontes plus larges). Là effectivement, l'impératif d'efficacité peut se faire jour avec force. La fréquence de cette recherche d'efficacité en fait une généralité, mais pas un fait systématique et encore moins un but. Je tente de ne pas mélanger la cause et la conséquence.
Pour la maîtrise de l'architecture, encore faut-il avoir donc pensé aux points de la scalabilité et de la redondance - et là où nous pouvons nous rejoindre, c'est que Robert n'a certainement pas atteint l'objectif (mais après tout, c'est une proposition initiale, personne n'est contraint d'en faire usage...).
Ce n'est pas un effet de style si on est passé d'une qualification de "système informatique" (et donc de direction informatique) à "système d'information" (et donc de "direction des systèmes d'information"). Il y a une logique derrière. Personnellement ça ne me dérange pas qu'on considère que l'informatique n'est qu'elle-même, un concept un peu "indépassable", mais c'est un signe si les "cellules de gestion de projets" et autres modalités d'organisations se multiplient dans les DSI pour modifier les habitudes et les approches.
Je n'ai rien, absolument rien à te vendre : je ne te rapporte pas un propos commercial, je ne te vends pas du rêve ; je te donne mon opinion de ce que j'ai pu trouvé après des heures à la bibliothèque universitaire ou en entretien. Tu ne prendras certainement pas les arguments, mais toi comme moi, nous nous ne nous adressons pas à l'autre mais aux lecteurs qui nous ont le mérite de nous lire.
Et je t'assure, évoquer les sciences de gestion dans les années 70 ou l'intérêt d'un travail ontologique au sein d'une organisation pour piloter le schéma de données et le développement applicatif d'une DSI n'a rien de bandant ! Au contraire, ça provoque le rejet et l'impatience (voire une pointe de mépris...).
Anecdote : lors de ma soutenance, mon jury me dit "propos passionnant, innovant [en réalité pas tant que ça, je fais une synthèse de travaux d'autres horizons pas encore rapprochés]. Comment voulez-vous vendre ça à une entreprise ?!" -> Je ne peux pas. L'historique culturel est en défaveur de l'approche "organisationnelle" des SI... mais des signes commencent à émerger.
Illustrons le propos. Un exemple que je suis attentivement : la ré-émergence du "no-/low-code", les services Amazon Lambda (idem chez Microsoft, IBM, Google... ces 3 dernières années), l'approche "fonctionnelle" sur tout un tas de langages très différents et une logique événementielle. Le schéma global de ces services :
1. un événement quelconque
2. un filtre
3. une fonction déclenchée, éventuellement avec la notion de grappes de travail derrière
4. une réponse renvoyée et/ou stockée.
Plutôt que d'agir sur l'efficacité d'une fonction, on dimensionne sa réplication (maîtrise des coûts : arbitrage sur le temps de calcul global plutôt que l'efficacité unitaire). L'orchestration des fonctions entre elles, créée l'applicatif. En gros tu as un stock de fonctions (ou de fonctionnalités, c'est-à-dire de sous-applicatifs), qui tu lies entre elles, de manière arbitraire, possiblement sans ligne de code pour l'utilisateur final.
Présentation ici (la vidéo explicite bien) :
https://aws.amazon.com/fr/lambda/
Ces services cherchent justement à minimiser les coûts globaux pour les clients. Ils reprennent de vieilles théories, qui ont facilement 30 ans, avec les systèmes experts, qui eux-même n'avaient aucunement besoin de personnes ayant des talents de codeurs pour faire des logiciels (je pense à CLips par exemple*), en l'adaptant à ce qui est possible aujourd'hui.
Réellement, ce n'est ni plus ni moins que la ré-invention un poil modernisé des systèmes experts.
(* : L'expression choisie était celle des maths en inspiration, car il n'y avait pas guère de possibilités d'une interface évoluée. Ce n'est plus le cas aujourd'hui et je serais heureux le jour où une personne qui n'a pas de compétence informatique, sera capable de faire un logiciel convenable, avec un code généré propre et relativement bien pensé, parce qu'il se sera concentré sur les besoins de son métier et pas plus. On y arrive, doucement.)
Le but est de moins chercher cette partie d'optimisation purement mixte logicielle/matérielle, mais d'aller vers une meilleure applicabilité du logiciel au global et pour répondre aux exigences des procédures. C'est le sens de l'histoire : sinon autant rester à l'assembleur (zéro abstraction, tu n'auras pas mieux en terme de performance).
Deux des exemples qui allient beaucoup de facettes que j'évoque :
- le projet européen SPECIAL (l'application d'une politique de sécurité à maillage très fin sur n'importe quel d'objets)
https://www.specialprivacy.eu/
- la thèse doctorale de Jérémy Lhez sur le "Filtrage, stockage et raisonnement sur de grands volumes de triplets RDF ordonnancés"
https://pastel.archives-ouvertes.fr/tel-02084022/document
Comme je l'ai indiqué auparavant dans les commentaires, c'est bien le métier qui fait l'outil et pas l'outil qui fait le métier. Il doit donc être efficient et après, éventuellement, performant.
Les grandes boîtes ont un temps d'avance du fait de leurs moyens justement, et elles ne sont déjà plus sur la question de la numérisation (terminée) mais de l'abstraction de leurs outils numériques (SAAS, "cloudification" et autres) :
- elles ne veulent plus piloter du code mais une interface et un traitement logique (interface + traitement = logiciel) ;
- elles veulent davantage de développements rapides (c-à-d écrits vite) et efficients ;
- elles ne veulent plus gérer de la dette technique ni de contraintes organisationnelles trop fortes à cause de problématiques informatiques.
L'efficacité (en octets traités/seconde), les profils techniques pointus, arrivent après, en support pour rester dans du temps de calcul raisonnable mais pas en chef orchestre ni en finalité (exemple des "product owners" qui ne sont plus plus des pilotes techniques et couvres d'abord les attentes fonctionnels).
Pour le reste :
- tu es probablement un très bon programmeur et je ne doute pas une seconde que tu aies une meilleure connaissance que moi, notamment pour la gestion fine stack ou heap. Pour Robert, ma priorité est davantage la mise en grappe du processus que l'usage de la mémoire, tout en continuant à assurer la possibilité de soutenir un modèle RDF ;
- tu as entièrement raison un protocole binaire est plus efficace qu'un protocole qui se lit humainement. Mais j'ai préféré qu'il soit lisible par le plus grand nombre (dans l'espace francophone). Sur le sujet nos positions sont irrésolubles.
Enfin et pour conclure là, les hypothèses sur lesquelles j'ai travaillé ces dernières années et qui me motivent encore aujourd'hui. Elles n'ont aucune force de lois. Je les donne ici, pour parfaire le contexte de mon propos.
A. HYPOTHÈSE N°1 – « IL EXISTE UN ‘AUTRE CHEMIN’ POUR LES SI. »
B. HYPOTHÈSE N°2 – « LE SI EXISTE DANS DES CADRES HUMAINS TRÈS CONTRAINTS. »
C. HYPOTHÈSE N°3 – « LA DIRECTION DES SI DOIT DÉSORMAIS ÉVOLUER FORTEMENT. »