[Touful Khan]

Plop.
Les années passant, j'ai à 46 ans (vg) la possibilité probable de pouvoir entamer une reconversion professionnelle d'ici probablement quelques mois. Etant accompagné pour cela par des intervenants extérieurs à la société qui m'emploie actuellement, il est de leur avis que faire du développement cadrerait bien à mes capacités et désirs (notamment le fait de ne pas spécialement avoir envie de devenir manager).
Seulement, voila, ce sont les premiers à avouer qu'ils ne sont pas des pros du dév', et perso je vois le dev comme les métiers de bouche: pas grand chose à voir entre un cuisinier, un fromager et un éleveur de bétail, pourtant réunis sous la même branche. Apparamment le "data" serait demandé actuellement, sauf que personne est foutu de me dire ce que c'est sauf qu'il faut "un peu" programmer.

C'est la que j'ai besoin de vous: pourriez-vous me détailler quelles sont les grandes branches du machin, les métiers accessibles et les durées de formation nécéssaires ? J'ai pas besoin d'un truc super détaillé, juste des lignes directrices. La nana du bureau m'a dit "ouais en 4 mois c'est bon" mais j'ai comme un doute. J'ai rien programmé depuis du shell unix y'a une vingtaine d'années.

[Jyharl]

Ben je t'ai dis la dernière fois qu'on en a parlé : SQL / Python et si tu veux faire du prévisionnel, du R.

Avec ces trois là, tu passe Data Analyst easy. Et oui, c'est ultra demandé en ce moment. Je suis entrain de coacher l'une de mes employées pour passer Data Analyst Junior, là elle vient d'être promu dans un truc qui y touche de près mais qui n'est pas encore 100% ce dont il s'agit.

Vu ton XP Pro, si tu intègre du SQL & Python à ton cursus, tu pourras sans problème passer CX (Customer Experience) qui requiert généralement de l'analyse de données.

Si tu veux plus d'info, tu sais où me trouver.

Bisous.

[Touful Khan]

Non mais qu'il faille apprendre un langage ok mais tu fais quoi avec ? Du prévisionnel de quoi, la météo ?
Je suis un non-spécialiste détaillez-moi même ce qui semble obvious.

[Jyharl]

On en a parlera en privé du coup parce que c'est assez spécifique. Dans ton cas le plus simple ce serait de passer CSX (Customer Service eXperience) vu ton XP Pro déjà acquise, ce serait dommage de ne pas l'utiliser.

Pistes vulgarisées et résumées :

- Le prévisionel c'est analyse de l'historique des données (en prenant en compte la croissance ou décroissance, la saisonalité, ou tout autre modifyer pertinent) et de réussir à peu ou prou +-10% me dire combien de ticket/chat/email/appels on recevra demain, la semaine prochaine, le mois prochain, dans un an, par langage et par channel si possible. L'impact de ce genre d'analyse aide les "Workforcer Managers" à gérer le staffing et/ou l'Outsourcing Manager à communiquer en avance aux presta comment ils doivent se staffer pour chaque langue. En bref, super primordial si tu veux atteindre tes SLAs. C'est bien gentil d'avoir un ART à 30 min ou 2 min mais si y a pas de prévisionnel derrière pour se staffer en adéquation avec les objectifs, ça ne va pas le faire. Ca aide aussi à ne pas sur-staffer et donc ça aide l'entreprise/le département à ne pas claquer de l'argent inutilement (ie. en anglais: operating at scale)

- SQL/Python - Il y a plein d'application en dehors de celle ci-dessus, tu as l'analyse de NPS / CSAT qui est la plus commune et que demanderont la majorité des entreprises via l'analyse de donnée), à sortir un Top 10 des "Pain points" des clients avec les suggestions de correction évidemment. Si t'ajoute à ça de l'AB Testing (propre et sérieux) pour chaque action corrective que tu entreprends, c'est pas mal.

L'analyse de donnée c'est vérifier le "yakafokon". Par exemple, aujourd'hui, je suis sûr que tu peux, de tête, me donner ce que tu pense être le top 10 des problèmes clients. Mais ce sera ta perspective. L'analyse de donnée est elle, objective et peu fortement varier de l'experience des Reps.

Après dans ton cas particulier je suggèrerai BI plus que pur Analyst (voire Workforce Manager, Operations Support ou autre). La différence c'est que BI est plus proactif et a des connaissances business alors que Data Analyst se contente d'executer et d'aller chercher les données qu'on lui dit d'aller chercher.
Je peux approfondir en privé si tu veux.

[Ed Wood]

Citation :

Publié par Jyharl

Pistes vulgarisées et résumées :

- Le prévisionel c'est analyse de l'historique des données (en prenant en compte la croissance ou décroissance, la saisonalité, ou tout autre modifyer pertinent) et de réussir à peu ou prou +-10% me dire combien de ticket/chat/email/appels on recevra demain, la semaine prochaine, le mois prochain, dans un an, par langage et par channel si possible. L'impact de ce genre d'analyse aide les "Workforcer Managers" à gérer le staffing et/ou l'Outsourcing Manager à communiquer en avance aux presta comment ils doivent se staffer pour chaque langue. En bref, super primordial si tu veux atteindre tes SLAs. C'est bien gentil d'avoir un ART à 30 min ou 2 min mais si y a pas de prévisionnel derrière pour se staffer en adéquation avec les objectifs, ça ne va pas le faire. Ca aide aussi à ne pas sur-staffer et donc ça aide l'entreprise/le département à ne pas claquer de l'argent inutilement (ie. en anglais: operating at scale)

- SQL/Python - Il y a plein d'application en dehors de celle ci-dessus, tu as l'analyse de NPS / CSAT qui est la plus commune et que demanderont la majorité des entreprises via l'analyse de donnée), à sortir un Top 10 des "Pain points" des clients avec les suggestions de correction évidemment. Si t'ajoute à ça de l'AB Testing (propre et sérieux) pour chaque action corrective que tu entreprends, c'est pas mal.

L'analyse de donnée c'est vérifier le "yakafokon". Par exemple, aujourd'hui, je suis sûr que tu peux, de tête, me donner ce que tu pense être le top 10 des problèmes clients. Mais ce sera ta perspective. L'analyse de donnée est elle, objective et peu fortement varier de l'experience des Reps.

Après dans ton cas particulier je suggèrerai BI plus que pur Analyst (voire Workforce Manager, Operations Support ou autre). La différence c'est que BI est plus proactif et a des connaissances business alors que Data Analyst se contente d'executer et d'aller chercher les données qu'on lui dit d'aller chercher.
Je peux approfondir en privé si tu veux.

En rouge c'est les mots que je ne comprends pas.
Mais après, j'ai rien compris. Ni ce qui semblait important, ni le fond de la chose. Même pas un petit peu en quoi les trucs s'articulait et encore moins, au quotidien ce que c'était comme travail.

Message supprimé par son auteur.

[Jyharl]

Sur certains mots, t'exagère Ed Wood et tu fais juste ton franchouillard de base sauf sur "action corrective" qui est bien français. Je suis désolé, il y a pas mal de termes dont je ne connais pas la traduction en français vu que je bosse en anglais. Mais Zygomatique étant dans le même cas, il devrait comprendre la majorité. Maintenant faire genre que tu ne comprends pas "channel" me fait me demander si tu trolle ou si tu es sérieux.

Sur d'autres, oui, c'est spécifique et prend en compte son expérience actuelle avec des termes précis d'un corps de métier qu'il connaît déjà (donc pas du tout généraliste d'où l'incompréhension par exemple j'estime qu'il est familier de NPS/CSAT), c'est bien pour ça que je suggérais à Zygomatique d'en parler en privé.

Edit pour en dessous : Merci Neirdan.

[Neirdan]

yakafokon = phonétique
presta = (sociétés) prestataires de services

BI = Business Intelligence https://fr.wikipedia.org/wiki/Inform...%A9cisionnelle
staffer = constituer une équipe (embaucher/former)
sur-staffer = embaucher trop de personnes (par rapport à la demande ou aux besoins)
Pain-point = point de douleur = difficultés
AB Testing = Test de plusieurs scénarios (scénario A vs scénario B, voir lequel fonctionne le mieux)
Action corrective = supprimer/contourner un pain point.

[Touful Khan]

Oui j'ai capté parce qu'il parle d'un domaine que je connais, mais je voulais quelque chose de plus large en fait. J'ai pas spécialement l'intention de rester dans le domaine dont il parle. La ce qu'il décrit c'est pas un métier c'est une fiche de poste.

[Jyharl]

Citation :

Publié par Zygomatique

Oui j'ai capté parce qu'il parle d'un domaine que je connais, mais je voulais quelque chose de plus large en fait. J'ai pas spécialement l'intention de rester dans le domaine dont il parle.

Okay, ma gueule alors.

Je trouve juste ça dommage de faire une croix sur presque 15 ans (20 ?) d'expérience dans un domaine quand tu as l'opportunité d'approfondir et de devenir un expert métier en ajoutant la data à ton expérience. Pourquoi une boite te prendrait en Analyst de Donnée Junior à 46 ans comparé à un p'tit jeune sorti des études ? Ta valeur ajoutée c'est ton expérience professionelle. Je pense que c'est une erreur de t'en éloigner mais à toi de voir.

Pour du plus large, je vais laisser les gens plus informés que moi te répondre du coup.

[Touful Khan]

Je fais pas une croix, je ne ferme juste aucune porte pour l'instant. J'ai édité plus haut, j'ai l'impression que tu fais plus une fiche de poste pour une boite spécifique qu'un descriptif de métier en fait. ^^

[Jyharl]

Citation :

Publié par Zygomatique

Oui j'ai capté parce qu'il parle d'un domaine que je connais, mais je voulais quelque chose de plus large en fait. J'ai pas spécialement l'intention de rester dans le domaine dont il parle. La ce qu'il décrit c'est pas un métier c'est une fiche de poste.

Ben non. C'est pas une fiche de poste et encore moins pour une boite spécifique. J'essaie de t'expliquer, suite à ta question précédente, comment le SQL, Python et R peut s'appliquer à ce que tu connais déjà vu que tu voulais des exemples concrets.

C'est difficile de considérer que ce que je dis est une fiche de poste vu que je te précise que :

1°) Ce sont des exemples d'applications à des trucs que tu connais.

2°) Je te cite au moins 3 voire 4 métiers voire domaines différents pour lesquels ça s'applique.

[Neirdan]

Pourtant l'exemple est clair.

Tu bosses pour un site de vente en ligne, tu es chargé d'analyser le tunnel d'achat et de voir à quelle étape l'abandon est le plus important, pour augmenter le taux de transformation. Les actions correctives sont menées par des front-end devs/UX designers (avec de l'AB testing), et toi tu analyses les nouveaux résultats.
Rinse repeat.

Message supprimé par son auteur.

[Touful Khan]

Citation :

Pourtant l'exemple est clair.

Oué mais son exemple se base sur un cas précis qu'il monte sur mes comps actuelles. C'est pas inintéréssant (Jyharl je te poke un de ces 4 mais c'est relou les conversations en chat) mais justement je cherche les trucs globaux et génériques qui peuvent s'appliquer à toutes les industries et que je connais pas. Après ce dont il parle à le mérite de la cohérence de parcours.

[Ed Wood]

Citation :

Publié par Jyharl

Sur certains mots, t'exagère Ed Wood et tu fais juste ton franchouillard de base sauf sur "action corrective" qui est bien français. Je suis désolé, il y a pas mal de termes dont je ne connais pas la traduction en français vu que je bosse en anglais. Mais Zygomatique étant dans le même cas, il devrait comprendre la majorité. Maintenant faire genre que tu ne comprends pas "channel" me fait me demander si tu trolle ou si tu es sérieux.

Sur d'autres, oui, c'est spécifique et prend en compte son expérience actuelle avec des termes précis d'un corps de métier qu'il connaît déjà (donc pas du tout généraliste d'où l'incompréhension par exemple j'estime qu'il est familier de NPS/CSAT), c'est bien pour ça que je suggérais à Zygomatique d'en parler en privé.

Edit pour en dessous : Merci Neirdan.

Je me suis douté qu'il s'avait de quoi tu parlais. Mais sans déconner, même les mots que je pouvais traduire, j'arrivais pas à comprendre les phrases, parce que pour le quidam c'est pas inné le contexte.

[Jyharl]

Citation :

Publié par Ed Wood

Je me suis douté qu'il s'avait de quoi tu parlais. Mais sans déconner, même les mots que je pouvais traduire, j'arrivais pas à comprendre les phrases, parce que pour le quidam c'est pas inné le contexte.

Désolé dans ce cas !

@Zygomatique : On peut faire un call à l'occasion, ce serait avec plaisir. Je laisse la place sur ce topic.

[Steel]

Hello,
That's my job !

Je suis aujourd'hui ingénieur décisionnel (= BI). Je peux te parler un peu du métier qui ne demande pas à proprement parler énormément de code (mais quand même une maîtrise technique sur des outils + une connaissance sur la manipulation de datasets + le langage SQL en LV2 de préférence, même si tout cela s'apprend bien sûr).

Sachant qu'en ce moment, on me propose de passer sur du Data Engineering, en Python, ce qui serait un gros changement de paradigme pour arriver au même résultat.
J'y reviens ensuite car ce sont des parties très en vogue en ce moment, la question de la transition se pose.

Pour autant, il reste toujours des équipes BI structurées à l'ancienne (l'ancienne d'il y a 4/5 ans, ce monde change tellement vite), donc selon où tu tombes, ça peut tout changer dans ton quotidien .

Du coup, je vais d'abord parler de ce que je connais, et ensuite proposer une projection sur la suite.

La BI "old-school", pour moi, c'est :
- De l'intégration de données (avec des ETL type Talend, ODI, Stambia, etc) => A partir de données brutes, on modélise, on joint les données en une forme utilisable dans des reportings. C'est souvent vu comme la partie "technique" du métier. C'est là où il y a le plus de besoins. Ce n'est pas forcément perçu comme étant très valorisant.
- Du reporting (type Business Objects ou Cognos) => Restituer de la data à des utilisateurs sous forme de tableaux de données Excel-like, parfois des graphiques de base, connectés directement à la base de données, avec des interfaces enrichies pour filtrer / manipuler
- De la dataviz (des outils type Tableau Software, Qlik Sense, Data Studio de Google et tant d'autres) => L'idée est de produire des graphiques et d'offrir une vraie interaction à la data à l'utilisateur.
- Parfois, du prédictif (sur du R, du Python). On parle aussi de Machine Learning (voir du Deep Learning sur la partie reconnaissance d'image / langage naturel). On va pas se mentir, c'est encore rare en BI. C'est une partie qui a pris de l'importance en même temps que la mode Data Engineer / Data Analyst / Data Scientist, du coup certaines teams sont encore perdues sur le sujet.

----

En général en BI, là où je suis passé (4 teams principalement, dont du retail / de l'industrie / du e-commerce), j'aurais juste ces remarques supplémentaires :
- Tout ce qu'on développe (du reporting, du tableau de bord) est destiné à des analystes métier, qui sont moins technique. La BI produit, elle n'analyse pas la donnée. Et, si tu avais envie de partir dans l'analyse, c'est très trompeur pour quelqu'un qui rejoint ce monde, donc je préfère te prévenir, c'est important
- Il y a quand même une notion d'analyse et de proactivité (je rejoins ce qui a été dit ici) => Il y a du dialogue avec les analystes métier, pour les cadrer un peu, appliquer des règles de gestion, vérifier que le même indicateur n'est pas calculé différemment dans l'équipe d'à côté, etc. Et à partir de là, on monte le pipeline avec l'intégration de données et la viz qui va bien.
- On peut être full-stack sur l'ensemble de la chaîne, mais en général les managers aiment bien des spécialistes de chaque branche.

----

On en vient à tout ce qui est Data : Engineer, Analyst, Scientist. Je rappelle qu'ici je propose une vision qui n'est pas encore très claire et qui n'est pas la même selon l'environnement.

Pour résumer le résultat :

Data Engineer = Intégration de données
Data Analyst = Reporting, Dataviz
Data Scientist = Prédictif.

La différence avec les métiers de la BI est, selon l'environnement, inexistante (dans ce cas là ce sont des termes marketing, on remplace "Dev ETL" par "Data Engineer") soit complète (et on bascule dans un monde plus technique).

Apparemment, un "vrai" Data Engineer devrait travailler en Python avec du code robuste, bien fiabilisé, bien testé pour intégrer la donnée. Pour résumer, produire le même résultat qu'avec de l'ETL avec l'interface graphique en moins. Avantage : le code devient portable et ne dépend plus d'un éditeur / la sécurité également. Inconvénient : la productivité, la dépendance à l'infra.

Un Data Scientist, c'est aussi du Python. Il y a des bibliothèques qui permettent d'appliquer des modèles de machine learning. Même si j'ai le sentiment que les entreprises ne les recherchent pas souvent (en France tout du moins). Mais ils aiment parfois en avoir pour montrer que leur société est dans le mood. Quand je vous parlais de marketing.

Un Data Analyst, en terme de tech, il me semble que ça reste selon le cas sur de la dataviz (Tableau / Qlik Sense), soit sur de l'étude statistique (R, Python).

----

En face de tout ça, tu as le liant du management agile qui est en vogue et qui est censé accroître ta productivité.
Parfois du Kanban, qui s'apparente à une liste de tâches que tu dois traiter dans la semaine et qui est géré par ton équipe client. Davantage en mode exécutant que spécialiste capable d'apporter un œil un peu neuf. On aime ou on aime pas

----

Voilà, c'est un pavé, c'est un écosystème complexe qui est encore en transformation, mais sur lequel on sait qu'il y a des besoins. La transformation, c'est surtout car les entreprises ont un enjeu de trouver la meilleure façon de faire dans le domaine. Du coup, il faut avoir une certaine capacité d'adaptation pour entrer dans ce monde, et accepter que tout puisse changer régulièrement.

[Caniveau Royal]

@Zygomatique
Ne te casses pas la tête à savoir exactement où dans le développement tu t'orienteras avant d'avoir appris les bases de la programmation.

L'ordinateur et la programmation à quoi servent-ils ? À tout faire.
Exactement comme une feuille de papier blanc et un crayon, où tu peux écrire un argumentaire, dessiner un chef d’œuvre ou un plan.

Depuis que j'ai commencé l'informatique, j'ai écrit des programmes pour : la comptabilité générale, la gestion de production, l'assurance vie, l'assurance santé, la distribution, les régies publicitaires...
On peut réfléchir et écrire sur n'importe quoi avec de la programmation. Il suffit de savoir ce que tu veux faire, et de le décrire.

Message supprimé par son auteur.

[Axxou]

[Je me permets d'utiliser ce poste pour une réorientation personnelle]

Je pensais justement à me reconvertir dans ce domaine, data analyste plutôt que data scientiste, suite à divers participation à des forums / discord.

Ce qui me bloque actuellement, c'est le manque de connaissance en mathématique ( venant d'un cursus plus géographique et informatique (géomaticien quoi), j'ai des notions de programmation Python et de SQL.



Dans quelles proportions, les attentes dans ce domaine sont importantes?

J'ai déjà téléchargé toutes les librairies depuis Anaconda par ailleurs.

[Jyharl]

@Steel : Super détaillé ! Merci. Ca résume plutôt bien.

Je rajouterai pour le côté Intégration de Données, maitriser les APIs (voire en développer soi-même) est de plus en plus important également. La majorité des outils ont un système d'API. Du coup je rajouterai le Javascript pour compléter.

Pour le reporting et la data visualization, dis-moi si je me trompe @Steel mais mon profond ressenti est que cela va tendre à disparaître parce que la majorité (et de plus en plus) des utilisateurs de ces données sont déjà sensibilisés à l'utilisation de données brutes et préfèrent faire leur aggregation de données eux-même. C'est beaucoup plus rapide & flexible plutôt que de demander à l'équipe Data de le faire. Mes collègues et moi on utilise Looker uniquement pour centraliser toutes nos données en une source unique mais on télécharge nos reports et on bosse dessus sur spreadsheet.

Il y a (en tout cas dans les 3 dernières boites pour lesquelles j'ai bossé) pas mal de défiance vis à vis des Tableau, Looker, etc. Vu que tout le monde s'arrache ces métiers, les entreprises sont généralement en sous-effectif. A noter également que, selon comment l'entreprise est structurée, les experts data ont de fortes chances d'être centralisés dans un même département et de bosser pour le reste de la boite.

Cette structure combinée au manque d'effectif mène à de l'intégration trop lente, qui ne suit pas la rapidité des autres départements (je parle en start-up ou tech). D'où le pain-béni qu'est Google Data Studio pour les gens comme moi qui agrègent différentes sources sous spreadsheet car je ne veux pas attendre 1 ou 2 trimestres que l'équipe Data intègre mon nouvel outil à Looker.

Mais je suis probablement biaisé, je suis passé Implementation Manager (et là @Steel va direct me haïr ) du coup je bosse tous les jours avec l'équipe data qui me hait aussi.

@Axxou : Statistiques et probabilités sont le plus important je dirais.
Tiens un très bon article vulgarisé sur l'AB Testing et quels maths ça demande (en anglais désolé).

[Caniveau Royal]

Citation :

Publié par Axxou

Ce qui me bloque actuellement, c'est le manque de connaissance en mathématique ( venant d'un cursus plus géographique et informatique (géomaticien quoi), j'ai des notions de programmation Python et de SQL.

C'est marrant parce que moi, ça fait 25 ans que je suis dans l'info pure et dure C, C++, Java, et je vais maintenant vers la géomatique et l'open data pour me changer les idées ! Et ce qui me bloque, c'est la maîtrise des statistiques descriptives : ACP, ACM, tout ça, je maîtrise mal, et inférentielles, j'en parle même pas. Plus le fait qu'on vous saoule grave avec le Big Data (genre : si tu travailles avec Spark il faudrait, dit la communauté, que tu apprennes Scala, le langage qui fait des bugs partout et dont ses créateurs ont un melon mais façon pastèque : ils sont sûrs que leur langage doit remplacer Java... ; Or Spark se programme très bien en Java ou en Python d'ailleurs). C'est Python qui a un très grand potentiel, aujourd'hui.

[Axxou]

Dans mon cursus, on a très rarement abordé la notion de big data et encore moins l'apprentissage de Scala.
Même sur https://georezo.net/ l'aspect big data est "inexistant".

Clairement depuis ma licence, Python est mis en avant dans la majorité des cas.

[Caniveau Royal]

C'est vrai. Mais plus tu exploites de l'open data (toutes les données souveraines, toutes les adjonctions que tu peux trouver à droite et à gauche venues de data.gouv.fr, de l'INSEE, etc.) et plus tes jointures, tes regroupements, et autres opérations réclament de la mémoire, que tu n'auras jamais en quantité suffisante. Et c'est là que le Big Data intervient, en premier lieu.