Tout est résumé ici :
https://www.commitstrip.com/fr/2020/...o-code-dream/?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Tout est résumé ici :
https://www.commitstrip.com/fr/2020/...o-code-dream/?
Une faute dans le titre
Bonjour,
-> "pour être un développeur de logiciels ni pour créer des applications de types professionnels."
-> remplacer par "professionnelles"
SINON, on trouvé des dev. assez cons pour coder un prog. de codage automatique,
sont'ils suicidaires ou éminemment cons ???
Cons? ils vont vendre leur outil comme des petits pains, ils sont loin d'être cons.Envoyé par oooopppp
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
J'ai beaucoup rigolé quand MS a proposé de remplacer pas mal de process de data via Flow comme outil low code.
Ca marche bien sur des petits trucs... Dans le cas contraire c'est une usine à gaz (qui requiert des compétences de dev, forcément) et qui peut être fait bien plus rapidement via du code ou du scripting... et avec de bien meilleures perfs...
Ca me rappelle la grande époque de VBA qui a créer des usines à gaz non-maintenable...
Quelques pensées citoyennes
[/INDENT]
Bonjour à tous,
Non, je ne suis pas développeur et vous pouvez dire que je suis incompétente sans rancune, mais j'espère que vous apprécierez tout de même ma contribution à cette discussion, car j'aimerais obtenir vos avis sur quelques pensées qui me sont venues à l'esprit en lisant cet article.
Je ne peux pas me débarrasser de l'impression de déjà-vu en lisant l'article et vos contre-arguments, notamment par rapport au développement des technologies de traduction. Quand j'ai fini mes études en linguistiques (2007), les universités et entreprises commençaient en masse à miser sur la traduction automatique. Bien évidemment, les traducteurs ne voyaient pas non plus comment un processus aussi complexe qu'une traduction pouvaient être faite par un logiciel plutôt qu'un humain ayant fait 4 ans d'études à ce sujet.
En gros, remplacez "informatique" par "traduction" et "low-code" par "machine translation" et ça reste à peu près pareil ;-)
1/ Tout part d'un désir de personnes qui ont besoin de solutions informatiques de ne plus dépendre de ... vous. Et oui, vous êtes plus compétents qu'eux, mais ils n'aiment pas devoir passer par vous pour faire les choses. Ces personnes sont prêtes à se contenter d'une qualité moyenne si elles peuvent faire elles-mêmes et la chose fait l'affaire à un coût réduit.
2/ Non, ça ne gêne pas certains développeurs de développer des produits qui vont bouffer le métier de leurs collègues. Ca ne fait pas d'eux des suicidaires, car ce ne sont pas eux qui seront concernés par d'éventuels pertes d'emploi.
3/ J'ai compris qu'aujourd'hui il reste de nombreux arguments pourquoi les outils low-code ne peuvent faire le boulot correctement. Mais ils sont bien développés par des personnes qui connaissent aussi bien que vous les défis? Qu'est-ce qui leur empêcheraient de trouver de bonnes solutions à cela?
4/ Le cauchemar de la maintenance. Pour les incompétents en cette matière, il est évident que ce ne sera pas leur problème de trouver des solutions pour cela. C'est quand-même vous les compétents n'est-ce pas. Je crains que vous allez voir diminuer votre contribution créative et augmenter votre frustration avec les outils qui vous seront imposés par des gens qui n'ont pas les priorités que vous.
Bon allez j'ai hâte que vous me détruisez pour que je comprenne que j'ai été trop pessimiste ;-)
Le VBA d'ailleurs n'était pas en cause. On peut coder propre en VBA. Il n'a pas toutes les petites astuces des langages modernes, mais permet de faire le boulot. A condition de connaitre son boulot, évidemment, ce qui n'était pas le cas des millions de para-programmeurs qui se sont perdus là-dedans.
Il y a toujours un calcul de rentabilité à faire. On peut économiser sur la qualité des traductions, au risque de voir les ventes faiblir. Ce n'est pas choquant de voir des gens peser le pour et le contre. Ce qui est choquant, c'est de voir des gens ne peser que le contre, et pas le pour (ou l'inverse, d'ailleurs)
La complexité assez irréductibles des tâches qu'on demande au code de faire. Je sais que je ressort toujours le même vieux lien, mais le code est fait de décisions. Dans le bloc technique qu'on met à disposition de l'utilisateur, on peut mettre toutes les décisions standard qu'on veut. Mais les décisions exotiques, celles qui font la valeur ajoutée de notre boite sur le marché, celles-là ne peuvent pas être livrées en standard. Et elles ne sont pas plus simples que les décisions standard (en moyenne, ça peut varier, hein). Donc même si on encapsule es difficultés techniques (ce qui moi me plait, personnellement), il reste toujours les difficultés fonctionnelles métier. qui, elles aussi, doivent être formalisées de manière propre pour marcher, et pour être maintenables. Et ça, c'est bien le métier du développeur.
Ben, tu viens de résumer 40 ans d'histoire sur le sujet. Pas mal pour quelqu'un qui dit ne rien y connaitre. Sauf que les couts de maintenance sont explosifs comparativement aux couts du projet. Si effectivement on accepte de payer 100 sur 10 ans pour économiser 1 tout de suite, ces outils peuvent avoir du charme. Mais il ne faut pas se voiler la face sur le poids de la dette technique. Et c'est ça que nous dénonçons : les vendeurs de ces produits éludent totalement la question de la maintenance, qui est pourtant vitale pour faire un calcul économique complet.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Low-Code / No Code
C'est de la trend bullshit commercial digital (celui du milieu levé) pour vendre des formations.
Des gars on voulu faire ça dans les années 90, aujourd'hui on se traine des ESB à la con, des pseudo language de merde (webdev, windev), etc...
low-code enfants
Bonjour
Est ce que vous connaissez des outils low code qu'on peut apprendre aux enfants 8/11 ans ( a part scratch que je connais deja ) ? et un sympa pour ado 12/14 ans ?
Ouais... Mc Donald et La Tour d'Argent à Paris sont tous les deux des restaurants. Juste que dans l'un d'entre on y mange de la merde. WordPress, c'est Mc Do. Après que le pro de la souris aura ajouté pleins de plugins pour simuler un semblant de compétences, son usine à gaz aura des perfs pourris et rejoindra le bataillon de tous ces sites de merde qui vident les batteries et font transpirer même des processeurs puissants.
Mais bon, c'est pas cher et WordPress répond à une demande, même si je regrette sa popularité.
ça me rappelle la méthode Merise
Et autres langages de spécifications. On nous disait alors (~1980) que bientôt on aurait plus besoin de programmeurs car le code serait directement généré à partir des specs.
Mais en fait, c'est quoi un langage de programmation ? Une autre manière de décrire les spécifications ! Donc le VRAI problème, ce n'est pas de coder, c'est de comprendre et décrire dans un "langage" quel qu'il soit ce qu'on a à faire faire à la machine !
Le no-code / low-code c'est vraiment du marketing
Comme je l'avais dit plus haut, c'est juste une autre façon de programmer, mais c'est de la programmation quand même
Il y a un autre aspect plus dérangeant : les promoteurs du no-code / low-code ne disent pas que "taper du code" c'est seulement la partie émergée de l'iceberg du développement logiciel.
Pour créer un bon logiciel, quelque soit les outils et la technologie, il faut (liste non exhaustive) :
- prendre le temps d'écouter les différentes catégories d'utilisateur pour comprendre leur besoin - le logiciel doit s'adapter aux utilisateurs et pas l'inverse
- parfois, aider l'utilisateur à formuler son besoin... car les gens ne savent pas toujours ce qu'ils veulent
- lister toutes les contraintes techniques sans en oublier aucune sinon risque d'aboutir à une impasse (format de fichier à utiliser, API tiers à utiliser, compatibilité avec un autre logiciel, système d'exploitation, hardware particulier éventuel, ...)
- élaborer un cahier des charges, définir les fonctionnalités du futur logiciel... et penser aux évolutions ultérieures envisageables
- concevoir la structure de données
- concevoir l'interface (Combien de fenêtres ? Qui serviront à quoi ? Quelle ergonomie ? Saisie graphique à la souris et/ou texte ? Avec quels éléments ? ...)
- concevoir les algorithmes correspondants aux différentes fonctions
- et enfin... coder.
Un logiciel ne se fait pas en tapant directement du code en tapant frénétiquement sur le clavier comme dans les films hollywoodiens
(Sauf pour les petits logiciels vraiment tout simples pour faire une tâche, typiquement un traitement par lot spécifique sur un ensemble de fichiers)
Il y a de nombreuses étapes de conception qui se font en amont, souvent même sans ordinateur, juste avec un crayon et du papier, avec une alternance de moments de réflexion seul et de moments d'échanges en équipe.
Tout le temps "économisé" sur la phase de conception en amont sera perdu en étant multiplié par 100 en phase réalisation
D'ailleurs ça c'est valable aussi en mécanique ou pour les travaux...
J'ai toujours regretté de ne pas avoir assez réfléchi avant de fabriquer quelque chose, mais je n'ai jamais regretté d'avoir passé trop de temps à réfléchir
Le codage, finalement, c'est presque un détail...
Résumer la création d'un logiciel au "code" c'est dénigrer totalement le développement
Quand deux personnes échangent un euro, chacun repart avec un euro.
Quand deux personnes échangent une idée, chacun repart avec deux idées.
Essaye avec Arduino : https://www.ictjournal.ch/news/2020-...loppements-iotBonjour
Est ce que vous connaissez des outils low code qu'on peut apprendre aux enfants 8/11 ans ( a part scratch que je connais deja ) ? et un sympa pour ado 12/14 ans ?
C'est amusant, car on programme non pas un ordinateur mais une petite carte qui peut être intégrée dans un jouet par exemple pour allumer des LED, faire des sons, et même faire bouger un petit robot avec des petits moteurs.
D'ailleurs il existe de nombreux kits tout faits, avec livret pédagogique. C'est quasiment du clef en main.
Ce qui est bien avec Arduino, c'est la courbe d'apprentissage qui est bien progressive :
- il est assez facile de faire des petits trucs tous simple
- on peut faire des choses complexes mais cela impose de mieux maitriser les concepts de la programmation
Pour équiper une classe, il existe des clones Arduino très économiques ce qui évite d'exploser le budget.
Les outils logiciels sont open source.
Dans le même genre, il y a les briques Lego Technic programmables, mais c'est assez cher.
A bientôt
Quand deux personnes échangent un euro, chacun repart avec un euro.
Quand deux personnes échangent une idée, chacun repart avec deux idées.
Différents outils
Bien d'accord avec ces propos plutôt mesurés, les outils ne remplacent pas les professionnels qui les utilisent. Le low-code permet de développer différemment.
Cet article (en anglais pardon) introduit les utilisations pertinentes faites des applications de développement: https://www.crust.tech/what-kind-of-...with-low-code/
je dérive un peu du sujet principal mais si sur une majorité de projets infos il y a de moins en moins de code c'est un gros truc comme G*thub qui risque d'en faire les frais...puisque le principe de ce système est de fournir de l'archivage de code.
et en plus cela a été racheté par Microsoft pour des milliards il n'y a pas longtemps.
Le développement low-code : un mensonge ? Oui, d’après l’architecte logiciel Jay Little
Le développement low-code : un mensonge ? Oui, d’après l’architecte logiciel Jay Little
Qui relance le débat sur l’avenir du métier de développeur sous la menace de l'intelligence artificielle
Le low-code est susceptible de remplacer le codage traditionnel d’ici 2024. C’est ce qui ressort d’une étude de Mendix, un éditeur de solutions low-code. Dans les chiffres du sondage, 87 % d’un lot de 556 entreprises répondantes, basées aux USA, au Royaume-Uni, aux Pays-Bas, en France et en Allemagne, envisagent d’accélérer le rythme de leur développement logiciel en s’appuyant sur les outils low-code au cours des deux prochaines années. Les tendances mises en avant viennent raviver le débat sur l’avenir du métier de développeur. En effet, qui dit low-code dit entrée en matière croissante de développeurs citoyens, c’est-à-dire de tiers qui ne sont pas des spécialistes de l’informatique au détriment de ceux qui le sont. Jay Little – architecte logiciel – prend position sur la question et explique pour quelles raisons il est d’avis que le low-code est de la poudre de perlimpinpin.
« J'écris des logiciels personnalisés depuis longtemps et l'une des choses qui m'agacent le plus, c'est lorsqu'un client adopte la position selon laquelle il existe une solution miracle qui réduira ou supprimera la complexité inhérente à cette tâche. Cela arrive plus souvent qu'on ne le pense et devinez quoi ? Ils ont presque toujours tort.
Peut-être suis-je un peu trop vieux et trop lâche pour mon propre bien, mais la vérité est que la création de logiciels pour d'autres personnes est extrêmement difficile. Contrairement à ce que pensent les non-praticiens, cette difficulté n'est pas imputable aux langages, outils et paradigmes de codage. Elle résulte en fait du fait que les clients et les développeurs ne prennent pas le temps de comprendre les causes profondes des problèmes qu'ils veulent résoudre et ne conçoivent pas une solution en fonction des conclusions que vous tireriez de ce processus.
Il ne suffit pas de coder l'outil tel qu'il est spécifié par le client. La première étape avant de commencer à coder est de valider l'existence et les détails du problème lui-même. La plupart des projets de codage sont lancés après que le client s'est rendu compte qu'il avait un problème et qu'il a décidé de demander un code qui, selon lui, le résoudra. En réalité, la plupart des clients ne sont pas des professionnels de la résolution de problèmes, alors que c'est précisément ce que font les développeurs de logiciels. Il nous incombe donc de valider l'approche suggérée par le client avant de lui faire perdre son temps et son argent en la développant », explique-t-il pour souligner que faire du développement informatique ce n’est pas pisser du code.
En gros, le low-code ne saurait faire disparaître les développeurs. Par contre, ce sont des outils qui leur sont destinés afin qu’ils gagnent en productivité. La question de leur adoption divise néanmoins dans le milieu sur des aspects comme la maintenance des logiciels produits à partir d’outils low-code.
Un avis qui rejoint celui de l’architecte logiciel Hosk
Le cauchemar de la maintenance des logiciels low-code
Selon Hosk :
- la création d'un logiciel est rapide, mais la maintenance dure des années et est plus coûteuse ;
- les logiciels créés par des développeurs citoyens vont créer une dette technique à grande échelle ;
- la création de nombreuses petites applications va créer un cauchemar de maintenance au sein de la filière informatique ;
- les frais généraux de maintenance ne cesseraient d'augmenter : « C'est comme si vous deviez maintenir des centaines de feuilles de calcul Excel avec des formules, un mauvais nommage, aucune cohérence et peu de documentation » ;
- les outils de développement low-code devraient être maintenus par des personnes compétentes en matière de low-code, qui se spécialiseraient dans ces compétences. Les équipes informatiques devraient se perfectionner dans les outils de développement low-code, ce qui augmenterait les coûts.
Hosk estime que les outils de développement low-code sont excellents pour créer de petites applications indépendantes, mais ils ont du mal à répondre aux exigences complexes : « À moins que le monde ne s'oriente vers des exigences simples, les logiciels low-code ne remplaceront pas 80 % de tous les logiciels créés. Le pouvoir du code est de créer des logiciels complexes conçus pour fonctionner exactement comme les entreprises et les systèmes le souhaitent. Il sera donc difficile de créer des logiciels complexes avec de nombreux développeurs travaillant en même temps avec des outils low-code. »
Les problèmes de sécurité et de données liés au low-code
Hosk est d’avis que pendant que les services informatiques se familiarisent avec les nouveaux outils low-code, il y aura des violations majeures de la sécurité parce que personne n'a compris comment verrouiller les outils de développement low-code. En sus, il faut du temps pour comprendre les nouveaux outils et créer les meilleures pratiques pour s'assurer qu'il n'y a pas de failles de sécurité ou de problèmes de données. La puissance des outils low-code serait que vous pouvez vous connecter aux médias sociaux comme Twitter, Facebook et d'autres systèmes et les données de l'entreprise peuvent se retrouver sur Internet.
Le low-code et le battage médiatique
Hosk entrevoit une explosion de la création d'applications low-code, mais aussi une augmentation de la demande de professionnels pour les besoins en maintenance et formation. Le développement low-code ne signera-t-il pas la fin des développeurs ou du code selon ce schéma : augmentation de la popularité, création de nombreux logiciels low-code ; problèmes de maintenance des logiciels low-code ; les développeurs créeront des centres d'excellence et guideront les développeurs citoyens vers les meilleures pratiques ;
le low-code sera utilisé pour de petites applications, pas pour tout le développement de logiciels exigeants.
Selon Hosk, les compétences des développeurs ne se limitent pas à l'écriture du code. Les développeurs sont des professionnels ayant des années d'expérience et de bonnes pratiques conçues pour créer des logiciels faciles à maintenir. Par contre, les développeurs citoyens et les équipes informatiques devraient constater que les logiciels low-code créés par des développeurs citoyens seront difficiles à prendre en charge, à maintenir et à étendre. C'est la raison, selon l’architecte logiciel, pour laquelle la révision du code par des développeurs expérimentés existe. Cela empêche la création de code de mauvaise qualité :
« Vous pouvez donner des outils de bricolage aux gens, mais cela ne fait pas d'eux des experts en bricolage, comme le montrent de nombreuses améliorations de la maison. Les améliorations apportées à la maison par des développeurs citoyens fonctionnent à court terme, mais il s'agit de lacunes à court terme qui finissent par être corrigées. »
Enfin, Hosk pense que les développeurs de logiciels ne seront pas remplacés, mais ils devraient être recyclés pour utiliser des outils low-code pour créer des logiciels : « Pour que les outils low-code soient efficaces, ils devront être créés en utilisant les meilleures pratiques, le déploiement, les revues de code et d'autres activités des développeurs professionnels. Le développement de logiciels low-code continuera à se développer, mais les exigences complexes et les grands systèmes dépasseront les capacités des outils low-code. À l'avenir, les outils de développement low-code créeront jusqu'à 50 % des applications et les solutions seront un mélange de low-code et de code. »
Source : Jay Little
Et vous ?
Les chiffres de ce sondage collent-ils avec la réalité dont vous êtes au fait ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Un des gros problèmes que je vois avec les "applications-citoyens", le "low-code", c'est non seulement, les problèmes de maintenance technologique mais aussi toute l'approche gestion et architecture des données.
Que ce soit avec des solutions comme celles de Mendix ou Apps de Microsoft, les "citoyens", "end-users" développent des applications qui gèrent leurs activités dans leur petit coin. Lorsque ces applications introduisent de nouveaux concepts de données et que, dans un autre coin du paysage métier, d'autres utilisateurs se disent que cette information est utile, l'interopérabilité entre les deux coins va être ardue, car l'application qui gère cette information aura été développée uniquement d'un point de vue "end-user" et pas avec des points de vue architecture des données et technique,
Soit parce que les concepts de données n'auront pas été suffisamment rendus génériques et transversaux, soit parce que les plates-formes d'échanges techniques de ces données n'existent pas.
Ces solutions sont dans les moyennes et grosses entreprises, IMO, le retour du fichier Excel et du ré-encodage comme mode d'échange des données entre différentes "applications-citoyens". Avec tous les risques que cela engendre.
Ce qui va sembler être un gain dans l'immédiat (parce qu'on donne aux end-users la possibilité de développer les outils dont ils ont besoin) devient vite un micmac et un danger en termes de pérennisation, de validité et propriété des données ainsi créées.
Je suis très d'accord avec toi cependant, dans ma société, on est confronté à trois problèmes :
_ Nos dev sont sous l'eau avec la gestion de nos "gros systèmes" (ERP, PLM etc) donc ils n'ont pas le temps de transmettre leur sagesse aux métiers qui se réfugient dans excel pour répondre à leur besoin.
_ Les métiers ne savent la plupart du temps pas ce qu'ils veulent et nos dev ne savent pas travailler sans cahier des charges.
_ Les métiers qui ont une bonne vision sur leur demande savent ce qu'ils veulent (je veux une machine X développée par chatGPT avec le langage Y et qui compte les cafés dans un camembert bleu) mais ne savent pas exprimer leur besoin (je veux un truc qui fait le café et qui les compte) ce qui mène à une guerre métier/SI chacun remettant en cause son interlocuteur sur le domaine où il n'est pas compétent.
Tout dépend de ce qu'on appelle "low-code" ou "no-code"
Est-ce qu'un blog créé avec WordPress est du "no-code" ?
Quand je vois qu'on considère un formulaire Microsoft Forms ou Google Forms comme un outil no-code, c'est un peu tiré par les cheveux et ça gonfle les chiffres
A ce moment-là, autant considérer n'importe quel fichier créé par n'importe quel logiciel comme du "no-code"
Ensuite, un langage de programmation graphique où on connecte des blocs logiques, un peu comme en électronique ou électrotechnique (exemple : programmation des automates de sécurité) et bien pour moi c'est du code quand même.
Quand deux personnes échangent un euro, chacun repart avec un euro.
Quand deux personnes échangent une idée, chacun repart avec deux idées.
Je pense que la différence se fait dans la manière d'obtenir le code. Soit, c'est une personne (normalement un développeur) qui tape le code, soit, c'est l'outil qui déduit le code d'après les informations transmises par l'utilisateur.Tout dépend de ce qu'on appelle "low-code" ou "no-code"
Est-ce qu'un blog créé avec WordPress est du "no-code" ?
Quand je vois qu'on considère un formulaire Microsoft Forms ou Google Forms comme un outil no-code, c'est un peu tiré par les cheveux et ça gonfle les chiffres
A ce moment-là, autant considérer n'importe quel fichier créé par n'importe quel logiciel comme du "no-code"
Ensuite, un langage de programmation graphique où on connecte des blocs logiques, un peu comme en électronique ou électrotechnique (exemple : programmation des automates de sécurité) et bien pour moi c'est du code quand même.
La plupart des IDE ont une partie "no-code". Le développeur dessine la fenêtre, place les différents champs, etc... La "fenêtre/fiche" obtenue (qu'importe le nom que l'IDE lui donne) contient du code que le développeur n'a pas saisi, et qu'il ne modifiera pas (généralement). Certains n'ont même pas conscience de son existence.
Au nom du pèze, du fisc et du St Estephe
Au nom du fric, on baisse son froc...
Ce n'est pas nouveau.
On parle seulement maintenant "d'architecture de la donnée" aux end-users, mais ça fait 15 ans que j'orbite dans les méthode de master data et golden data, avec toute l'architecture de synchro qui peut aller avec, c'est juste un des termes actuellement à la mode. Mais on est encore assez loin d'avoir quelque chose de compris par une population non-technique.
Ce qui a changé c'est surtout la profusion "d'appli génératrice low-code" comme la stack powerautomate, alors qu'avant ce n'était que des échanges Excel (et si c'était évolué c'était via du VBA ou des addins).
Les end-users sont toujours les mêmes avec les mêmes défis et les même problèmes.
Maintenant ces outils mis dans les mains de ceux dont c'est le métier permettent de mettre en place des solutions rapides pour certains petits process (ou pour du poc), à moindre coût.
Pour faire le parallèle, j'avais eu une discussion avec un statisticien qui pestait de la même façon contre les gars qui faisaient de la BI et se pensaient statisticiens parce qu'ils sortaient des graphiques via les outils utilisé par le statisticien...
C'est un domaine qui coûte cher.
Et je re rejoint entièrement là dessus que si c'est mal (ou pas) géré, tu vas générer des surcoûts voire des gros problèmes..
Il suffit de voir à quel point de nombreuses entreprises ont été emmerdées avec les data processing agreement à sortir quand GDPR a dû être pris en compte...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager